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I.  INTRODUCTION 


In  the  late  spring  of  2007,  a  combat  weary  15th  Marine  Expeditionary  Unit 
(MEU)  re-embarked  on  their  Expeditionary  Strike  Group  (ESG)  ships  to  begin  a  steady 
voyage  home  to  Camp  Pendleton,  CA.  Nearly  2000  Marines  loaded  themselves  and  their 
operational  gear  onboard  the  ESG’s  amphibious  flagship,  USS  BOXER  (EHD-4). 
Einally  removed  from  the  insurgency  hot-bed  within  A1  Anbar  province,  the 
administration  of  a  twice-extended,  nine  and  a  half  month  deployment  was  just  about  to 
begin.  Prior  to  reports,  evaluations,  awards,  and  e-mails  reconnecting  families  could 
even  be  considered,  the  MEU’s  communications/IT  personnel  required  some  300 
unclassified  workstations  to  integrate  back  onto  the  BOXER’s  Eocal  Area  Network 
(EAN).  Although  routinely  practiced  onboard  amphibious  ships  the  large-scale  network 
integration  was  slow  and  burdensome. 

Surrounded  by  arguably  the  latest  IT  throughout  the  ship,  both  Sailors  and 
Marines  could  not  benefit  from  technology  to  aid  the  arduous  process  of  how 
workstations  were  integrated.  Not  only  restricted  to  frequently  used  Marine  equipment, 
EAN  integration  is  exceedingly  difficult  with  any  group  the  capable  amphibious  platform 
could  sea-base  for  missions,  anticipated  or  unexpected.  LHDs  have  the  potential  to 
conduct  a  multitude  of  military  and  humanitarian  tasking  allowing  Government  or  Non- 
Government  Organization  (GO/NGO)  causes,  respectfully,  to  seek  out  assistance  from 
the  U.S.  Navy.  To  be  viable,  their  technology  will  have  to  be  able  to  circumvent 
traditional  USN  enterprise  views  of  hardware  and  software  standardization  and 
compliance  policy.  Current  architecture,  technology,  and  business  practices  have  become 
distracted  with  such  policy  where  existing  technology  inhibits  rather  than  enhances 
overall  productively. 

Whether  planning  for  a  Marine  landing  onto  an  opposed  beachfront  or  supporting 
Doctors  Without  Borders  during  Humanitarian  Assistance/Disaster  Relief  operations,  the 
dynamic  environment  the  U.S.  Navy  operates  within  today  calls  for  the  ability  to  lead 
through  hosting  traditional  and  unanticipated  disparate  organizations.  When  time  is  a 

critical  resource.  Naval  afloat  units  lack  the  ability  to  rapidly  and  efficiently  facilitate 
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inorganic  equipment  that  enables  those  who  embark  to  support  U.S.  objeetives.  This 
chapter  provides  a  background  on  the  observed  problem  and  states  the  thesis  purpose. 
Additionally,  research  questions,  scope,  and  the  approach  to  this  thesis  are  presented. 

A.  BACKGROUND 

Today’s  United  States  Department  of  Defense  is  braeing  for  a  future  where 
institutional  beliefs  are  directly  questioned  in  efforts  to  better  posture  its  service  members 
for  improved  readiness.  Top  government  and  military  leadership  have  indieated  that 
effective  pursuits  of  national  interest  cannot  be  achieved  one-dimensionally  through  a 
single  braneh  of  military  service  or  solely  through  U.S.  joint  military  involvement.  The 
dynamic  environment  the  present  world  has  to  offer  requires  joint,  coalition,  interagency, 
state,  and  non-state  eoordination.  The  latest  U.S.  National  Military  Strategy  pushes  this 
theme  further  through  the  encouragement: 

To  facilitate  interageney  and  enable  international  interoperability  before 
crises  oeeur”  (Mullen,  2011).  While  considering  The  Future  of  Warfare, 
Hammes  (2005)  attempts  to  pinpoint  a  fundamental  need  “to  shift  our 
focus  from  pure  technology  to  technology  that  supports  the  human 
elements  required  for  the  long-term,  interagency  efforts  required  to  win 
future  conflicts,  (p.  277) 

Arguably,  the  first  aspect  to  begin  moving  toward  improved  interoperability  is  to 
foeus  on  how  the  U.S.  military  eonducts  operations  jointly,  from  service  to  serviee. 
Seamless  eoordination  internally  through  our  branehes  of  military  can  serve  as 
benchmarks  to  foster  interageney  and  foreign  unity  of  intended  efforts.  Furthermore, 
communieation  between  organic  and  inorganic  personnel  should  be  the  first  priority. 
U.S.  Joint  Operations  Doctrine  (2008)  requires  that  “assigned  forees  should  be  eapable  of 
complementary  mutual  support  and  full  communications  interoperability”  (p.  189). 

When  asked  about  technology  needs  and  capabilities  wished  for  (in  her  future 
budgeting  requirements/wish  list),  former  Expeditionary  Strike  Group  Two  (ESG-2) 
Commander,  Rear  Admiral  Miehelle  Howard  stated  a  need  for  “interoperability  as  we 
move  around  theater,  not  just  within  Navy  forees,  but  with  other  serviees,  joint,  eoalition 
partners  and  non-govemmental  organizations”  (CHIPS,  2011).  Rear  Admiral  Howard 
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had  the  opportunity  to  experience  how  redefined  interoperability  within  and  outside 
traditional  means  was  necessary  for  mission  success,  yet,  in  reality,  could  only  address 
the  shortfall  within  her  wish  list  and  not  within  her  provisioned  budget.  As  Commander 
of  ESG-2,  she  stood  witness  to  the  U.S.  Navy’s  emerging  requirements  to  effectively 
collaborate  and  coordinate  through  commonality  in  technology.  Moreover,  leaders  like 
Rear  Admiral  Howard  have  come  to  the  realization  that  the  Navy  must  also  take  a  leading 
role  among  disparate  entities.  Often  that  role  is  best  facilitated  through  the  actual  onboard 
hosting  of  organizational  and  operational  units. 

The  U.S.  Navy  has  a  unique  ability  to  sea-base,  establishing  major  operational 
centers  upon  international  and  coalition  waters.  Sea-basing  facilitates  the  structure  for 
operations  and  grants  central  platforms  for  agreed  intentions.  “Sea-based  operations  use 
revolutionary  information  superiority  and  dispersed,  networked  force  capabilities  to 
deliver  unprecedented  offensive  power,  defensive  assurance,  and  operational 
independence  to  Joint  Force  Commanders”  (Clark,  2002).  Although  naval  platforms  are 
tasked  to  support  this  invaluable  operational  agility,  formidable  challenges  of  force 
integration  arise  when  addressing  joint  or  coalition  interoperability.  Currently,  manning 
levels,  evolved  processes,  and  enterprise  technology  result  in  unrealistic  integration 
expectations,  costly  man-hour  usage,  restricted  battlefield  preparation,  and  compromised 
Situational  Awareness  (SA). 

Could  recent  advances  in  information  technology  and  virtualization  benefit  joint 
integration  with  currently  deployed  elements  and  their  systems?  A  step  in  the  right 
direction  would  be  to  enhance  the  surface  fleet’s  ability  to  economically  communicate 
with  any  trusted  agent  able  to  add  value  to  meet  mission  objectives.  This  collaboration 
and  invaluable  information  exchange  may  come  in  very  conventional  or  unconventional 
forms  and  over  unanticipated  platforms.  The  ability  to  move  with  a  desired 
unconventional  uniformity  will  hinge  on  our  military’s  ability  to  improve  its 
communications  interoperability.  Arguably,  the  most  experienced  armed  services 
conducting  combined  operations  are  the  U.S.  Navy  and  Marine  Corps  (USMC). 
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Although  within  the  same  department,  the  proud  tradition  and  unique  capabilities 
distinguishing  the  Navy  and  Marine  Corps  team  also  harbors  differences  in  personnel, 
procedures,  and  equipment. 

“Joint  operational  flexibility  will  be  greatly  enhanced  by  employing  pre¬ 
positioned  shipping  that  does  not  have  to  enter  port  to  offload”  (Clark,  2002).  Few  other 
services  embrace  the  missions  and  daily  practice  of  joint  interoperability  better  than  the 
U.S.  Navy’s  Amphibious  Readiness  Groups  (ARGs),  former  Expeditionary  Strike 
Groups.  Primarily  established  for  the  amphibious  landing  of  Marine  Expeditionary  Units 
(MEUs),  ARGs  share  a  wealth  of  other  missions  absolutely  requiring  joint,  coalition, 
federal,  and  non-governmental  partnership  to  include  (22d  MEU,  2011): 

•  Peacekeeping/Enforcement 

•  Humanitarian/Disaster  Relief 

•  Security  Operations 

•  Noncombatant  Evacuation  Operations 

•  Reinforcement  Operations 

•  Amphibious  Raids/ Assaults/Demonstrations 

•  Tactical  Deception  Operations 

•  Airfield/Port  Seizures 

•  Show-of-Eorce  Operations 

•  Reconnaissance  and  Surveillance 

•  Seizure/Recovery  of  Offshore  Energy  Eacilities 

To  accomplish  these  multiple  types  of  mission,  a  MEU  will  embark  over  2200 
Marines  composed  of  (typical  example  provided  by  22d  MEU): 

1.  Command  Element  (CE) 

169  personnel.  Serves  as  the  headquarters  for  the  entire  unit  and  allows  a  single 
command  to  exercise  control  over  all  ground,  aviation,  and  combat  service  support  forces 
(22d  MEU,  2011). 
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2,  Ground  Combat  Element  (GCE) 

1200  personnel.  Provides  the  MEU  with  its  main  combat  punch.  Built  around  a 
Marine  infantry  battalion,  the  GCE  is  reinforced  with  tanks,  artillery,  amphibious 
vehicles,  engineers,  and  reconnaissance  assets  (22d  MEU,  2011). 

3,  Aviation  Combat  Element  (ACE) 

417  personnel.  The  ACE  consists  of  a  composite  medium  helicopter  squadron 
containing  transport  helicopters  of  various  models  and  capabilities,  attack  helicopters  and 
jets,  air  defense  teams,  and  all  necessary  ground  support  assets  (22d  MEU,  2011). 

4,  MEU  Service  Support  Group  (MSSG): 

275  personnel.  Providing  the  MEU  with  mission-essential  support  such  as 
medical/dental  assistance,  motor  transport,  supply,  equipment  maintenance,  and  landing 
is  the  mission  of  the  ECE  (22d  MEU,  2011). 

The  most  routine  ARG  evolution  encompasses  the  embarkation  and  debarkation 
of  the  Marines  in  support  of  “amphibious,  security,  noncombatant  evacuation, 
humanitarian  assistance,  and  special  operations”  (15th  MEU,  2011).  Because  MEUs  ride 
their  respective  amphibious  surface  ships  for  months  while  steaming  toward  their  theater 
of  operations,  a  successful  embark  will  facilitate  a  successful  debark. 

Prior  to  the  transit,  embarking  Marines  are  required  to  integrate  with  the  ship’s 
infrastructure  in  order  to  seamlessly  continue  their  planning  for  upcoming  operations. 
Differing  standards  between  host  ship  and  MEU  computing  platforms  create  a  quagmire 
of  identifying  compatibility  and  ensuring  security  standards  are  upheld.  General  attempts 
at  streamlining  surface  ships  network  management  have  fallen  short  for  addressing 
inorganic  shipboard  riders. 

In  a  recent  2“‘*  Elect  hosted  ESG-2  and  2“‘*  Marine  Expeditionary  Unit  exercise. 
Bold  Alligator  2011,  multiple  incompatibilities  were  discovered  raising  concerns  about 
their  “ability  to  respond  to  a  dynamic  threat”  (Anderson,  2011).  Marines  and  other 
military  or  civilian  organizations  have  typically  been  required  to  perform  a  full  scan  or, 
most  likely,  a  hard  drive  wipe  and  reimage,  if  they  wish  to  connect  to  a  host  ship’s 
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network.  Illustrated  in  a  later  ehapter,  this  current  practice  includes  all  Navy  Marine 
Corps  Intranet  (NMCI)  workstations  for  the  2200  Marines  within  an  embarking  MEU  on 
their  assigned  ships  for  deployment  and  causes  a  substantial  delay  for  required 
C2  planning  prior  to  operations. 

From  a  Navy  Staff  and  Marine  perspective,  basic  network  interoperability  and 
incompatibility  lies  with  their  legacy  NMCI  workstations  onboard  the  ships  they  intend  to 
embark.  Since  its  introduction,  NMCI  has  been  met  with  mixed  reviews.  Much  of  the 
frustration  has  stemmed  from  the  lack  of  compatibility  between  U.S.  Navy  platforms  and 
the  shore  based  NMCI  inorganic  workstations.  The  incompatibility  of  U.S.  Navy  afloat 
platform  networks  with  shore  based  NMCI  and  inorganic  workstations  has  been  shown  to 
inhibit  information  workflow,  integration  of  planning,  and  timeliness  of  action  in  support 
of  assigned  operational  objectives  for  staff,  crew  and  embarked  personnel  onboard  U.S. 
Navy  platforms. 

It  is  important  to  first  understand  what  the  Navy  Marine  Corps  Intranet  is  and  why 
it  exists.  The  U.S.  Navy  NMCI  program  was  an  AC  AT  I  program  of  record,  with  a 
contract  cost  of  $9.3  billion  extending  from  1999  to  2010.  A  new  contract  has  since  been 
implemented  extending  remnants  of  NMCI  into  the  foreseeable  future.  The  Navy  and 
Marine  Corps  advertised  the  intranet  as  the  answer  to  all  their  computing  and 
communication  needs  in  the  online  realm.  NMCI  was  initially  created  to  “provide  an 
interoperable  command  and  control  network  needed  for  transitioning  to  a  net-centric 
environment”  and  consolidated  over  6,000  disparate  networks  into  one  (Hewlett-Packard, 
2011).  When  NMCI  was  delivered,  it  became  clear  that  it  was  not  available  to  the  most 
important  group  in  the  Navy  and  Marine  Corps,  the  deployed  war  fighter.  According  to 
Christopher  Ragano  (2006)  of  ONR,  “deployed  forces,  although  they  may  have  NMCI 
equipment,  find  that  the  equipment  does  not  support  their  mission,  and  they  have  to  carry 
out  work-arounds  using  other  equipment”  (Jordan,  2006,  p.  9).  As  such,  U.S.  Navy 
personnel  have  been  unsatisfied  with  the  overall  performance  of  NMCI.  The  GAO 
(2006),  Government  Accountability  Office,  found  that  “the  end  user  satisfaction  rate  was 
approximately  74  percent,  below  the  target  of  85  percent”  (Jordan,  2006,  p.  10).  The 
GAO  also  found  that  operational  users  (commanders  and  network  operators)  had  a  much 

6 


lower  satisfaction  rate  (Jordan,  2006,  p.  10).  These  numbers  are  up  from  60  percent, 
which  were  reported  in  2006  but  are  still  well  below  the  target  (Jordan,  2006,  p.  10). 

Over  a  decade  after  its  inception,  potential  technology  finally  exists  that  may 
provide  solutions  to  the  incompatibility  issues  of  NMCI,  as  well  as  non-NMCI  users, 
while  improving  information  workflow,  integration  of  planning,  and  timeliness  of  action 
in  support  of  assigned  operational  objectives  for  staff,  crew  and  embarked  personnel 
onboard  U.S.  Navy  platforms.  Review  of  the  current  deployment  of  virtualized  computer 
technology  and  solid  state  memory  technology  can  bolster  arguments  as  to  the  potential 
solutions  to  the  NMCI  and  its  general  incompatibility  issue.  Virtualization,  VMware, 
thin-client  desktops  and  solid  state  memory  may  provide  the  answers  to  these  issues. 

B,  PROBEM  STATEMENT 

The  incompatibility  of  U.S.  Navy  afloat  platform  networks  with  shore-based 
NMCI  and  inorganic  workstations,  along  with  choke  points  in  the  embarkation  processes, 
inhibits  information  and  workflow,  integration  of  planning,  and  timeliness  of  action  in 
support  of  assigned  operational  objectives  for  staff,  crew,  and  embarked  personnel  of 
U.S.  Naval  vessels. 

C,  PURPOSE  STATEMENT 

The  purpose  of  this  study  is  to  assess  whether  if  virtualization  technology,  paired 
with  solid  state  drives  and  process  re-engineering  onboard  U.S.  Naval  afloat  platforms, 
can  improve  work  flow,  integration  of  planning,  and  timeliness  of  action  in  support  of 
nominal  or  assigned  operational  objectives  for  staff,  crew,  and  embarked  personnel  of 
U.S.  Naval  vessels. 

D,  RESEARCH  QUESTIONS 

1 .  Do  hosting  Naval  platforms  have  adequate  facilities  to  foster  full  integration 
and  collaboration  of  embarking  personnel  spanning  all  operational  possibilities? 
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2.  How  can  Virtual  Desktop  Infrastructure  (VDI)  and  solid  state  memory 
equipment  be  leveraged  to  achieve  higher  level  of  integration  amongst  disparate 
organizations? 

3.  How  can  the  integration  of  embarking  personnel  and  their  necessary  equipment 
be  modeled  and  analyzed  a  for  better  understanding  of  current  and  improved  practices? 

4.  What  are  the  risks  and  benefits  resulting  from  a  ship-hosted  Virtual  Desktop 
Infrastructure  (VDI)  for  embarkables? 

5.  What  research  has  been  done  or  is  there  current  practice  advancing  the  use  of 
virtualization  or  VDIs  either  commercially  or  militarily? 

6.  What  are  the  technical  capabilities  of  major  VDI  commercial  organizations? 

7.  How  could  a  revised  model  aid  in  predicting  host  vessel  hardware  requirements 
for  a  VDI  in  order  to  better  understand  practical  costs? 

E.  SCOPE 

This  study  will  focus  on  the  effectiveness  and  practically  of  VDI  and  SSD  for 
embarkables  on  U.S.  Navy  ships  and  how  the  integration  of  new  technology  can  improve 
current  processes.  It  will  focus  specifically  on  risks  and  benefits  to  information  and  work 
flow,  integration  of  planning,  and  timeliness  of  action  in  support  embarked  personnel  on 
U.S.  amphibious  platforms. 

F.  APPROACH  AND  METHODOLOGY 

Literature  review,  system  analysis,  application  testing,  and  SME  interviews  will 
be  used  to  collect  data  and  information.  Equally  large  amounts  of  literature  review,  and 
data  and  system  analysis  will  be  required  to  adequately  frame  the  problem  statement  and 
fully  address  our  research  questions.  Application  testing  and  a  majority  of  our  interviews 
have  been  conducted  on  and  around  our  time  participating  with  Trident  Warrior  2011. 
With  the  knowledge  we  acquire  through  these  methods,  we  will  begin  to  draw 
conclusions  and  detail  our  understanding  on  the  effectiveness  and  practicality  of  VDI 
onboard  Naval  afloat  platforms. 
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Action  Research,  “concerned  to  ereate  organizational  change  and  simultaneously 
study  the  proeess,”  is  best  suited  for  this  method  of  researeh  (Baskerville  &  Myers,  2004, 
pp.  329-330).  Literature  research,  prior  experience,  and  system  testing  onboard  WASP 
will  help  identify  underlying  causes  and  further  develop  theoretieal  assumptions.  System 
analysis  of  embarkable  integration  will  foster  an  understanding  of  current  practiee  and 
allow  for  suggestions  toward  an  improved  end  state.  Aetion  taken,  or  intervention,  will 
encompass  the  Trident  Warrior  Next  Generation  Technology  (NGT)  Virtual  Desktop 
Infrastructure  (VDI)  for  embarkables  efforts. 

G.  THESIS  ORGANIZATION 

I.  Introduction.  Brief  overview  of  the  background,  problem,  and  purpose 
of  the  research. 

II.  Virtualization  Technology.  Provides  a  general  understanding  of 
virtualization,  its  background,  applications  and  benefits. 

III.  Solid  State  Drive  Teehnology.  Provides  a  general  understanding  of  solid 
state  drives,  its  baekground,  applieations  and  benefits. 

IV.  Amphibious  Integration.  Used  to  develop  an  understanding  of  shipboard 
integration  processes,  networking  practices  and  teehnology  needs. 

V.  Assessment  of  Trident  Warrior’  1 1  VDI  onboard  USS  WASP  (LHD 
Analysis  of  virtualized  desktops  as  tested  through  the  2011  Trident  Warrior 
initiative. 

VI.  Re-engineering  Amphibious  Integration.  Present  a  model  to  assess  the 
practicality  of  VDI  and  SSD  onboard  USN  platforms  in  the  adjustment  of 
shipboard  embarkation  processes. 

VII.  Conclusions.  Discusses  key  areas  where  virtualization  technology 
promotes  agile  enterprise  arehitecture  and  improvements  to  observed  business 
processes  supporting  integration. 
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II.  VIRTUALIZATION  AND  THIN  CLIENT  TECHNOLOGY 


A,  GENERAL  DISCUSSION 


In  the  last  decade,  virtualization  has  become  a  popular  subject  that  is  touted  as 
possibly  revolutionizing  networking  and  computing.  In  its  most  basic  form, 
virtualization  allows  a  PC  or  server  to  run  multiple  operating  systems,  a  guest  and  a  host, 
on  one  machine  and  is  illustrated  in  Figure  1,  which  compares  a  non-virtualized  system 
against  a  virtual  system  (Vaughn,  2006).  Through  the  use  of  a  hypervisor,  a  software 
technology  that  “emulates  a  hardware  device  for  each  virtual  operating  system  and 
handles  each  operating  system’s  communications  with  the  CPU,  the  storage  medium,  and 
the  network,”  a  server  or  PC  can  run  many  operating  systems  simultaneously  (Vaughan, 
2006,  p.  12).  This  allows  for  the  complete  optimization  of  a  PC  or  server  and  can  provide 
multiple  virtual  machines,  or  a  virtual  desktop  infrastructure  (VDI),  to  the  end  users.  The 
virtual  machines,  in  turn,  can  provide  all  the  benefits  of  a  standalone  PC  without  the  cost 
of  acquisition  or  physical  set-up  and  maintenance.  VDIs  can  be  created  ad  hoc  as 
computing  needs  change. 


Without  virtualization 


With  virtualization 


Source:  Intel 


Figure  1 .  Non-Virtualized  Platform  vs.  Virtualized  Platform  (From  Vaughn,  2006) 


Most  modem  computers  mn  dual  and  quad  core  processors.  The  Department  of 
Defense  and  the  general  public  are  buying  computer  systems  believing  that  they  are 
obtaining  superior  performing  machines  but  this  may  not  be  the  case.  The  tmth  is, 
operating  systems  routinely  do  not  take  full  advantage  of  the  processing  power  of  today’s 
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dual  and  quad  core  servers  and  PCs.  Aeeording  to  the  IDC,  the  International  Data 
Corporation,  servers  are  only  “utilizing  10-15%  of  their  total  eapacity”  (VMware,  2011). 
This  indieates  eompanies,  the  general  publie,  and  our  armed  forces  are  paying  for 
capabilities  that  they  possibly  will  never  utilize.  Virtualization  ean  remedy  this 
underutilization  and  save  money  wasted  on  hardware.  Organizations  have  reported  “60- 
80%  utilization  rates”  through  the  use  of  virtualization  (VMware,  2011).  This  may 
become  extremely  eritical  as  the  United  States  government,  eommereial  organizations, 
and  eitizens  in  general  are  looking  for  ways  to  accomplish  more  while  spending  less. 

In  addition  to  the  underutilization  of  proeessing,  an  underutilization  of  memory 
exists  as  well.  A  study  eonducted  by  Intel  eonfirmed  this  apparent  underutilization  in  a 
study  that  showed  that  only  “50  percent  of  approximately  3,000  servers  tested  used  no 
more  than  1  GB  of  memory”  (Intel,  2010,  p.  2)  and  by  “excluding  the  top  quartile, 
analysis  showed  that  for  75  pereent  of  servers,  maximum  memory  consumption  averaged 
about  1  GB,”  (Intel,  2010,  p.  2)  and  is  depieted  in  Figures  2  and  3  (Intel,  2010,  p.  2). 


Figure  2. 


Average  Memory  Consumed  by  Quartile  (From  Intel,  2010,  p.2) 
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Figure  3.  Server  Percentage  by  Ram  (From  Intel,  2010,  p.  2) 

In  general,  computers  today  are  far  more  powerful,  have  far  more  memory,  and, 
as  a  whole,  are  much  more  capable  than  their  counterparts  from  just  a  couple  of  years 
ago.  Today’s  machines  are  “often  under-used,  incur  significant  space  and  management 
overhead,  and  the  increased  functionality  that  had  made  operating  systems  more  capable 
has  also  made  them  fragile  and  vulnerable”  (Rosenblum  &  Garfinkel,  2005,  p.  39). 
Because  of  this,  virtualization  “will  be  less  a  vehicle  for  multitasking,  as  it  was  originally, 
and  more  a  solution  for  security,  reliability  and  integration.”  (Rosenblum  &  Garfinkel, 
2005,  p.  39).  As  the  Navy  looks  to  expand  its  mission  capability  by  conducting  more  and 
more  other  than  war  operations,  it  will  need  to  look  at  the  best  and  most  cost  effective 
means  of  integrating  outside  organizations  while  protecting  itself  from  intrusion  into  its 
networks. 

B.  HISTORY 

Virtualization  was  originally  used  in  the  mid-1960s.  During  this  decade,  personal 
computers  were  not  available,  meaning  computing  only  “belonged  to  large,  expensive 
mainframe  hardware”  systems  (Rosenblum  &  Garfinkel,  2005,  p.  39).  IBM  was  an  early 
dominant  force  in  computing  and  used  virtualization  heavily  within  mainframes  since 
early  systems  did  not  have  near  the  processing  power  of  today’s  servers  or  even  today’s 
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PCs.  Virtualization  provided  a  “way  to  logically  partition  mainframe  computers  into 
separate  virtual  machines”  (VMware,  2011).  This  partitioning  allowed  mainframes  to 
“run  multiple  applications  and  processes  at  the  same  time”  (VMware,  2011).  With  little 
or  no  processing  power,  miniscule  amounts  of  memory  compared  to  today’s  standards 
and  overall  crushing  costs,  getting  the  most  out  of  the  mainframes  then  was  a  must. 

The  reduction  of  costs  for  hardware  and  the  rise  of  modem  multi-tasking 
operating  systems  lead  to  the  demise  of  virtualization.  By  the  1980s,  the  world  moved 
away  from  virtualization  all  together.  The  “broad  adoption  of  Windows  and  the 
emergence  of  Linux  as  server  operating  systems  in  the  1990s  established  x86  servers  as 
the  industry  standard”  and  lead  to  the  retreat  from  virtualization  technology  and  methods 
(VMware,  2011).  With  the  adoption  of  x86  servers  new  challenges  arose.  These 
challenges  included; 

1.  Low  Infrastructure  Utilization 

Typical  x86  server  deployments  achieve  an  average  utilization  of  only  10%  to 
15%  of  total  capacity,  according  to  International  Data  Corporation  (IDC),  a  market 
research  firm.  Organizations  typically  mn  one  application  per  server  to  avoid  the  risk  of 
vulnerabilities  in  one  application  affecting  the  availability  of  another  application  on  the 
same  server  (VMware,  2011). 

2.  Increasing  Physical  Infrastructure  Costs 

The  operational  costs  to  support  growing  physical  infrastmcture  have  steadily 
increased.  Most  computing  infrastmcture  must  remain  operational  at  all  times,  resulting 
in  power  consumption,  cooling  and  facilities  costs  that  do  not  vary  with  utilization  levels 
(VMware,  2011). 

3.  Increasing  IT  Management  Costs 

As  computing  environments  become  more  complex,  the  level  of  specialized 
education  and  experience  required  for  infrastmcture  management  personnel  and  the 
associated  costs  of  such  personnel  have  increased.  Organizations  spend  disproportionate 
time  and  resources  on  manual  tasks  associated  with  server  maintenance,  and  thus  require 
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more  personnel  to  complete  these  tasks.  According  to  Gartner  Research  (2004),  for  every 
dollar  an  organization  spends  on  hardware,  it  spends  an  additional  $3.50  to  support  it 
over  its  lifetime  (VMware,  2011). 

4,  Insufficient  Failover  and  Disaster  Protection 

Organizations  are  increasingly  affected  by  the  downtime  of  critical  server 
applications  and  inaccessibility  of  critical  end  user  desktops.  The  threat  of  security 
attacks,  natural  disasters,  health  pandemics  and  terrorism  has  elevated  the  importance  of 
business  continuity  planning  for  both  desktops  and  servers  (VMware,  2011). 

5.  High  Maintenance  End-User  Desktops 

Managing  and  securing  enterprise  desktops  present  numerous  challenges. 
Controlling  a  distributed  desktop  environment  and  enforcing  management,  access  and 
security  policies  without  impairing  users’  ability  to  work  effectively  is  complex  and 
expensive.  Numerous  patches  and  upgrades  must  be  continually  applied  to  desktop 
environments  to  eliminate  security  vulnerabilities  (VMware,  2011). 

To  combat  these  new  challenges  caused  by  the  adoption  of  the  x86  servers  as  the 
standard,  alternative  methods  have  to  be  adopted.  Not  a  new  method  by  any  means, 
though  one  that  has  been  used  in  the  past  with  success,  virtualization  is  again  proving  to 
be  the  answer  to  flaws  and  challenges  presented  with  current  computing  needs. 

C.  STATE  OF  VIRTUALIZATION 

Some  giants  of  computing,  Microsoft,  Sun  Microsystems,  Intel,  and  IBM  are  all 
jumping  into  the  business  of  virtualization  and  expect  to  earn  billions  of  dollars  in  the 
sales.  The  sales  of  virtualization  systems  in  2008  totaled  $6.7  billion  and  were  expected 
to  grow  to  $11.7  million  by  2011  (Vaughan,  2008,  p.  13).  In  the  coming  five  years 
“North  America  and  European  virtualization  aggregate  markets  will  top  $218  Billion” 
(Market  Intel  Group,  2011).  It  is  estimated  that  “almost  75  percent  of  enterprises  in  the 
U.S.  have  already  deployed  virtualization  in  one  form  or  another,  and  the  virtualization 
market  is  growing  by  approximately  26  percent  [annually]  on  average”  (Vaughan,  2006, 
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p.  12).  It  is  estimated  that  the  “number  of  servers  worldwide  using  virtualization  has 
grown  from  just  under  175,000  in  2004  to  just  over  1  million  in  2009  (Vaughan,  2006, 
p.  12). 

These  trends  in  virtualization  system  sales  indicate  that  virtualization  adoption  is 
not  a  small  niche  movement.  The  commitment  of  key  corporations  to  develop,  produce 
and  sell  systems  and  the  expected  growth  of  these  systems  is  a  clear  indicator  of  the  ever¬ 
growing  demand  for  virtualization.  For  this  kind  of  growth  and  commitment  to  take 
place,  virtualization  must  present  a  compelling  case  for  use  and  has  done  so  to  this  point 
in  time. 

D,  ADVANTAGES  OF  VIRTUALIZATION 

As  discussed  previously,  virtualization  allows  for  multiple  operating  systems  to 
be  run  on  single  servers  or  PCs  but  it  also  provides  many  other  advantages  as  well. 
According  to  VMware  there  are  five  main  advantages  to  the  use  of  virtualization: 

Get  more  capability,  performance,  and  value  out  of  existing  resources:  Pool 
common  infrastructure  resources  and  break  the  legacy  “one  application  to  one  server” 
model  with  server  consolidation.  (VMware,  2011) 

Reduce  datacenter  costs  by  reducing  physical  infrastructure  and  improving 
server  to  admin  ratio:  Fewer  servers  and  related  IT  hardware  means  reduced  real  estate 
and  reduced  power  and  cooling  requirements.  Better  management  tools  let  you  improve 
your  server  to  admin  ratio  so  personnel  requirements  are  reduced  as  well  (VMware, 
2011). 

Increase  availability  of  hardware  and  applications  for  improved  business 
continuity:  Securely  backup  and  migrate  entire  virtual  environments  with  no  interruption 
in  service.  Eliminate  planned  downtime  and  recover  immediately  from  unplanned  issues 
(VMware,  2011). 

Gain  operational  flexibility:  Respond  to  market  changes  with  dynamic  resource 
management,  faster  server  provisioning  and  improved  desktop  and  application 
deployment  (VMware,  2011). 
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Improve  desktop  manageability  and  security:  Deploy,  manage  and  monitor 
seeure  desktop  environments  that  users  ean  aeeess  loeally  or  remotely,  with  or  without  a 
network  eonnection,  on  almost  any  standard  desktop,  laptop  or  tablet  PC  (VMware, 
2011). 

E.  VIRTUALIZATION  AND  THE  USN/USMC 

As  illustrated  in  the  introduction,  there  exists  a  significant  demand  for  efficient 
interoperability  onboard  ARGs.  This  plea  extends  to  both  professional  and  personal 
needs.  Given  the  traditionally  limited  amount  of  time  available  to  integrate  workstations 
compared  to  the  sheer  number  of  personnel  that  embark,  a  clear  call  for  virtualization 
presents  itself  The  embarkation  of  MEUs  allows  for  the  greatest  potential  of  process  and 
physical  improvement  through  the  use  of  virtualization  technology. 

The  Marines  embark  ARGs  more  frequently  than  any  other  group  but  they  are  not 
the  only  type  of  unit  which  embarks.  Navy  Command  Staffs,  government  organizations 
and  non-governmental  organizations  may  all  embark  on  an  ARG  separately  or  together. 
At  the  mercy  of  integration  processes  illustrated  later,  each  of  these  organizations 
requires  joint  operability  and  connectivity  to  efficiently  plan  for,  and  execute  their 
assigned,  often  extremely  short-notice,  tasking.  Through  the  use  of  virtualization,  all 
embarking  groups  could  have  the  ship’s  approved  operating  system  and  updated  security 
pushed  directly  their  carry-on  systems.  This  would  greatly  reduce  the  time  required  from 
the  ship’s  company  for  integration  and  allow  ship  riders  to  get  to  work  almost 
immediately.  During  crisis  response  situations,  the  ability  to  work  as  soon  as  boots  hit 
the  deckplates  is  critical  to  overall  mission  success. 

Virtualization  allows  groups  outside  the  normal  realm  of  the  Department  of 
Defense  to  embark  without  concern  for  encroachment  of  the  ship’s  actual  network.  By 
providing  virtual  systems  to  embarked  groups,  a  layer  between  the  main  network  and  the 
virtual  system  exists  through  the  use  of  a  hypervisor.  According  to  VMware  (2011): 

While  virtual  machines  can  share  the  physical  resources  of  a  single 
computer,  they  remain  completely  isolated  from  each  other  as  if  they  were 
separate  physical  machines.  Isolation  is  an  important  reason  why  the 
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availability  and  security  of  applications  running  in  a  virtual  environment  is 
far  superior  to  applications  running  in  a  traditional,  non-virtualized 
system. 

Those  with  virtual  machines  will  not  have  a  direct  path  to  sensitive  information 
that  may  exist  within  the  network  or  a  path  to  bring  down  the  network.  Also,  each  virtual 
machine’s  permissions  can  be  quickly  and  precisely  controlled,  quelling  any  concerns 
over  security.  The  Navy  and  Marine  Corps  could  be  able  to  work  with  an  unexpected 
mission  contributor  with  comparatively  less  concern  for  compatibility  or  security. 

Further,  virtualization  has  the  potential  to  reduce  the  amount  of  hardware  and 
software  required  to  meet  mission  tasking.  Virtualization  optimizes  servers,  which 
reduces  the  need  for  an  overabundance  of  servers  to  do  the  same  amount  of  processing  as 
a  virtualized  system.  Less  overall  demand  for  servers  processing  leads  to  less  hardware 
usage.  This  in  turns  leads  to  a  reduction  in  the  need  for  manpower  and  the  ability  to 
assign  manpower  to  where  it  is  better  served.  Along  with  the  reduction  in  manpower, 
fewer  servers  require  less  power  to  run  as  well.  Less  power  onboard  Navy  vessels  equates 
to  less  fuel  being  burned.  Onboard  Navy  vessels,  any  way  to  save  fuel  is  looked  upon 
favorably.  The  Honorable  Ray  Mabus,  Secretary  of  the  Navy,  stated; 

We  are  also  doing  this  (reducing  fuel  usage)  to  be  better  war  fighters.  A 
navy  ship  is  at  its  most  vulnerable  when  refueling.  The  USS  Cole  was 
refueling  in  the  port  of  Aden  in  Yemen  when  it  was  attacked  in  2000. 

Each  of  these  reductions  is  a  reduction  in  cost  incurred  by  the  Navy. 
(McKenna,  201 1,  p.  29) 

Through  virtualization,  servers  and  computers  are  optimized.  Optimization  is  not 
just  a  physical  measure,  but  also  a  monetary  measure.  The  Department  of  Defense  is 
continually  looking  at  ways  to  save  money  without  losing  operational  capabilities. 
Because  the  Navy  and  Marine  Corps  must  do  more  with  less,  virtualization  is  a  way  to 
achieve  this  goal.  Through  virtualization  the  USN  and  USMC  can  expand  joint  mission 
capability  by  opening  the  availability  of  hardware  and  applications.  Typically,  the  DoD 
will  buy  a  specialized  or  unique  type  of  hardware  or  application  that  works  well  for  the 
group  or  unit  but  it  will  lack  capabilities  to  jointly  work  with  other  groups  or  bring  them 
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on  board.  Through  the  improved  seeurity  and  eonfidence  provided  by  the  virtual 
environment,  naval  vessels  ean  utilize  new  or  different  hardware  or  applications  on 
the  fly. 

These  new  capabilities  may  allow  them  to  more  effectively  meet  mission 
requirements  or  increase  joint  interoperability.  In  terms  of  software,  license  management 
is  improved  significantly.  DoD  units  would  only  have  to  acquire  minimal  copies  of 
required  software  to  disseminate  to  all  virtual  machines,  vice  having  to  buy  multiple  or 
unnecessary  enterprise  copies  and  load  them  on  all  physical  stations.  By  expanding  joint 
mission  capability,  reducing  the  amount  of  physical  hardware  and  manpower  required, 
and  improving  security,  virtualization  may  be  worth  the  initial  cost  in  order  to  save  for 
the  future.  This  will  allow  for  the  USN  and  USMC  to  rapidly  adapt  and  adjust  to  ever 
changing  computing  and  mission  requirements.  By  improving  both  the  range  and  time 
agility  of  the  organizations,  they  become  more  capable  to  adapt  and  overcome  at  a  more 
affordable  and  justifiable  cost. 

As  mentioned  Navy  and  Marine  differences  both  distinguish  and  detract.  The  use 
of  VDI,  and  its  ability  to  virtualize  numerous  desktops,  would  take  the  USN  and  USMC 
from  a  department  that  reflects  short-sited  diversification  to  one  that  reflects  modern 
coordination.  Virtualization  would  allow  for  organizations  to  integrate  customer  services 
while  still  allowing  the  different  groups  to  maintain  their  unique  operational 
requirements.  This  ability  opens  up  further  possibilities  to  work  with  groups  outside  the 
DoD  and  expands  the  mission  capabilities  of  the  USN  and  USMC  to  more  than  just  war 
fighting. 
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III.  SOLID  STATE  MEMORY 


A.  GENERAL  DISCUSSION 

As  discussed  in  the  previous  ehapter,  virtualization  and  the  establishment  of  sea- 
based  VDI  ean  provide  many  benefits  to  any  organization  afloat.  However,  this 
teehnology  is  only  one  pieee  of  the  puzzle  in  implementing  a  sueeessful  solution.  The 
utilization  of  VDI  systems  with  modifying  or  replacing  typical  IT-21  server  farms 
presents  many  inherent  ehallenges.  Two  of  these  ehallenges  stand  out  above  others. 
They  are: 

1.  Performance.  The  I/O  eonstraints  of  disk-based  systems  result  in  poor 
performanee.  If  a  virtual  desktop  fails  to  perform  as  well  or  better  than  a  physical 
desktop,  end  users  eomplain  and  produetivity  suffers.  Unfortunately,  delivering  the 
performanee  most  enterprises  need  requires  raeks  of  hardware  that  quiekly  make  VDI 
impraetieal  (Fusion  io,  2011,  p.  I). 

2,  High  and  Unpredictable  Costs.  The  initial  outlay  to  purehase  NAS  or  SAN 
systems  is  enormous.  On  top  of  this,  system  administration,  power,  cooling,  and 
colocation  fees  beeome  an  ever-inereasing  operating  expense. 

To  fully  realize  the  potential  benefits  provided  by  a  virtual  desktop  infrastrueture, 
storage  eonsiderations  along  with  eost  must  be  weighed,  determined  and  implemented 
effectively.  According  to  Siebert  (2011),  “implementing  a  virtual  desktop  infrastrueture 
(VDI)  involves  many  eritical  eonsiderations,  but  storage  may  be  the  most  vital”  (Siebert, 
2011). 

The  most  diffieult  and  troublesome  ehallenge  faeed  when  setting  up  a  virtual 
desktop  infrastrueture  environment  “is  aceommodating  the  periods  of  peak  usage  when 
storage  I/O,  input/output,  is  at  its  highest”  (Siebert,  2011).  Input/output  refers  to  “any 
program,  operation  or  deviee  that  transfers  data  to  or  from  a  eomputer  and  to  or  from  a 
peripheral  deviee.  Every  transfer  is  an  output  from  one  deviee  and  an  input  into  another” 
(Siebert,  2011).  The  largest  periods  of  storage  I/O  issues  when  running  a  VDI  exist 
during  “boot  storms,”  or  when  large  numbers  of  users  boot  up  applieations  or  operating 
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systems  at  the  same  time.  “Initial  startup  of  a  desktop  is  very  resouree-intensive  activity 
with  the  operating  system  and  application  doing  a  lot  of  reading  from  disk”  (Siebert, 
2011).  Once  a  storm  has  been  started  it  may  continue  for  minutes  or  last  up  to  hours 
before  it  stops.  During  the  storm,  the  VDI  cannot  and  will  not  accept  any  inputs  and 
cannot  produce  any  outputs  until  the  storm  has  cleared.  This  leaves  the  end  users  without 
a  fully  operational  computer  system  for  possibly  hours. 

The  same  issue  can  occur  during  peak  usage  times  and  during  shut-down  storms. 
“Events  like  patching  desktops,  antivirus  updates/scans”  and  heavy  applications  workload 
can  all  lead  to  storage  EO  issues  (Siebert,  2011).  To  deal  with  these  issues,  it  is  critical  to 
determine  the  data  storage  infrastructure  required  to  handle  peak  period  challenges. 

When  setting  up  a  VDI  the  “the  key  measurement  for  storage  is  lOPS,”  or  the 
amount  of  input  and  output  operations  per  second  (Siebert,  2011).  With  the  use  of 
virtualization  comes  the  creation  of  “a  highly  random  I/O  pattern  from  each  host.  Adding 
additional  VMs  to  a  host  results  in  an  exponential  increase  in  random  I/O  operations  per 
second.  The  result  is  that  every  server  in  the  environment  is  a  potential  lOPS  consumer 
meaning  that  storage  system  lOPS  is  more  important  than  air”  (Crump,  2010,  p.  1).  With 
the  creation  of  a  handful  of  VMs  there  may  only  be  a  moderate  amount  of  resources 
consumed.  As  stated  before,  when  many  VMs  are  created  and  are  in  use,  the  amount  of 
I/Os  in  use  grows  exponentially.  Using  the  VMware  rule  of  thumb  that  a  VM  uses  around 
fifty  lOPS  per  VM,  we  can  determine  that  a  host  providing  fifteen  VMs  will  need  around 
750  lOPS.  Based  upon  Trident  Warrior  experiments  and  observation,  the  number  of  lOPS 
required  per  VM  is  closer  to  150  lOPS.  This  means  that  the  same  fifteen  VM 
infrastructures  would  produce  closer  to  2,250  lOPS.  If  an  organization  were  to  run 
25  VMs,  that  would  bring  the  amount  of  lOPS  to  3,750.  A  medium-sized  virtual 
infrastructure  of  50  VMs  would  reach  187,000  lOPS  for  the  virtual  environment  (Crump, 

2010,  p.  2). 

The  amount  of  lOPS  for  a  VDI  should  be  estimated,  as  it  may  be  impossible  to 

actually  determine,  prior  to  its  implementation.  Since  lOPS  are  ''sustained  levels  of  EO 

demand  and  EO  capacity,  the  average  usage  of  a  system  needs  to  be  considered.”  The 

average  EO  loads,  however,  should  not  be  the  benchmark  in  which  a  VDI’s  storage  needs 
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are  based  upon.  Instead  the  peak  I/O  loads  based  upon  the  amount  of  expeeted  usage  and 
the  amount  of  VMs  required  must  be  eonsidered  and  faetored  into  the  development  of  a 
VDFs  storage  needs  in  order  to  provide  the  best  user  experienee. 

There  are  other  eonsiderations  for  the  seleetion  of  the  type  of  storage  that  is 
required  when  setting  up  a  VDI.  Performanee  parameters  sueh  as  read  and  write 
eapabilities,  and  spin  rates  should  be  eonsidered.  Cost  is  another  faetor  that  must  be 
eonsidered  as  well  and  ineludes  factors  such  as  acquisition,  maintenance,  and  overhead 
costs  to  operate. 

This  leads  to  the  type  of  storage  possibilities.  The  two  main  types  of  storage 
drives,  spinning  disk  drives,  typically  made  up  of  SAS  and  SATA,  and  solid  state  drives. 
There  are  pros  and  cons  associated  with  each  of  these  types  of  mediums  and  a  direct 
comparison  is  provided  in  Table  1  (Wikipedia,  2012). 


Attribute  or 
characteristic 

Solid-state  drive 

Spinning  disk  drive 

Spin-up  time 

Almost  instantaneous; 
nothing  mechanical  to 
“spin  up.”  May  need  a 
few  milliseconds  to 
come  out  of  an 
automatic  power-saving 
mode. 

May  take  several  seconds. 

With  a  large  number  of  drives, 
spin-up  may  need  to  be 
staggered  to  limit  total  power 
drawn. 

Data  transfer  rate 

SSD  technology  can 
deliver  rather  consistent 
read/write  speed, 
typically  ranging  from 
about  lOOMB/s  to 
500MB/S,  depending  on 
model.  When  accessing 
individual  smaller 
blocks,  the  performance 
will  usually  degrade 
from  that.  In  general, 
the  speeds  are 
continuously  improving. 

When  reading  or  writing  a 
continuous  track,  a  HDD  can 
access  data  roughly  at  speed  of 
lOOMB/s.  However,  due  to 
need  of  seeking,  the  actual 
transfer  rates  will  almost 
always  be  much  lower. 
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Attribute  or 
characteristic 

Solid-state  drive 

Spinning  disk  drive 

Random  access 

About  0.1  ms  -  many 
times  faster  than  HDDs 
because  data  is  aceessed 
direetly  from  the  flash 
memory 

Ranges  from  5-10  ms  due  to 
the  need  to  move  the  heads 
and  wait  for  the  data  to  rotate 
under  the  read/write  head. 

Read  lateney  time'-^^^ 

Generally  low  because 
the  data  ean  be  read 
direetly  from  any 
location;  In  applications 
where  hard  disk  seeks 
are  the  limiting  factor, 
this  results  in  faster  boot 
and  application  launch 
times  (see  Amdahl’s 
law). 

Generally  high  since  the 
meehanieal  components 
require  additional  time  to  get 
aligned 

Consistent  read 
performance^^ 

Read  performance  does 
not  ehange  based  on 
where  data  is  stored  on 
anSSD 

If  data  is  written  in  a 
fragmented  way,  reading  baek 
the  data  will  have  varying 
response  times 

Fragmentation 

There  is  usually  very 
little  benefit  to  reading 
data  sequentially 
(beyond  typieal  FS 
bloek  sizes),  making 
fragmentation  a  void 
issue  for  SSDs. 
Defragmentation 
process  also  makes 
additional  writes  on  the 
NAND  flash  cells  that 
already  have  a  limited 
cycle  life.  It  is  also 
uncertain  whether 
defragmentation  would 
arrange  the  data  in  a 
truly  sequential  order,  as 
the  drive  itself  can  again 
remap  it  to  various 
positions. 

File  systems  on  HDDs  may 
fragment  after  continued 
operations  of  erasing  and 
writing  data,  espeeially 
involving  large  files. 

Therefore,  periodieal 
defragmentation  is  required  to 
maintain  ultimate 
performance. 

Acoustic  levels 

SSDs  have  no  moving 
parts  and  make  no 
sound 

HDDs  have  moving  parts 
(heads,  spindle  motor)  and 
have  varying  levels  of  sound 
depending  upon  model 
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Attribute  or 
characteristic 

Solid-state  drive 

Spinning  disk  drive 

Mechanical 

reliability 

A  lack  of  moving  parts 
virtually  eliminates 
mechanical  breakdowns 

HDDs  have  many  moving 
parts  that  are  all  subject  to 
failure  over  time 

Maintenance  of 
temperature 

SSDs  do  not  usually 
require  any  cooling 
maintenance  and  they 
can  tolerate  higher 
temperatures  than 

HDDs.  High-end 
enterprise  models 
delivered  as  add-on 
cards  may  include  heat 
sinks  to  dissipate  heat 
generated  by  its  chips. 

Air-forced  ventilation  is 
recommended  for  desktop 
hard  drives  to  avoid  build-up 
of  heat.  Otherwise,  bad 
sectors  on  its  media  can 
appear  later  and/or  its  lifespan 
will  diminish  over  time.  HDDs 
designed  for  laptops  do  not 
need  as  much  cooling,  but  heat 
issues  are  a  matter  of  concern 
with  them  too. 

Susceptibility  to 

environmental 

factors 

No  flying  heads  or 
rotating  platters  to  fail 
as  a  result  of  shock, 
altitude,  or  vibration 

The  flying  heads  and  rotating 
platters  are  generally 
susceptible  to  shock,  altitude, 
and  vibration 

Installation  and 
mounting 

As  for  SSD,  as  long  as 
it’s  mounted  securely  to 
its  place,  the  position 
and  installation 
mechanism  do  not  have 
much  of  impact  to  its 
normal  use.  Most 
ordinary  SSDs  have  all 
components  (except  for 
power  and  data 
connectors)  encased 
inside. 

While  installing  a  hard  disk 
drive,  one  must  take  care  of 
sufficient  cooling  and  sturdy 
mounting.  Additionally 
accessories  to  dampen 
vibration,  noise  and 
mechanical  shocks,  can  be 
installed.  The  printed  circuit 
board  underneath  of  a  HDD  is 
usually  exposed  and  any 
conductive  material  can  not  be 
let  to  short-circuit  the 
components  or  electronic 
contact  points. 

Magnetic 

susceptibility 

No  impact  on  flash 
memory 

Magnets  or  magnetic  surges 
can  alter  data  on  the  media 

Weight  and  size 

The  weight  of  flash 
memory  and  the  circuit 
board  material  are  very 
light  compared  to  HDDs 

Higher  performing  HDDs 
require  heavier  components 
than  laptop  HDDs  (which  are 
light,  but  not  as  light  as  SSDs) 
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Attribute  or 
characteristic 

Solid-state  drive 

Spinning  disk  drive 

Parallel  operation 

Some  flash  controllers 
can  have  multiple  flash 
chips  reading  and 
writing  different  data 
simultaneously 

HDDs  have  multiple  heads 
(one  per  platter)  but  they  are 
connected,  and  share  one 
positioning  motor. 

Write  longevity 

Flash-based  SSDs  have 
a  limited  number  of 
writes  (1-5  million  or 
more)  over  the  life  of 
the  drive.  Software 
controllers  manage  this 
limitation  in  such  a  way 
that  drives  can  last  for 
many  decades  before 
failure.  SSDs  based  on 
DRAM  do  not  have  a 
limited  number  of 
writes. 

Magnetic  media  do  not  have  a 
similar  limited  number  of 
writes  but  are  susceptible  to 
eventual  mechanical  failure. 

Secure  writing 
limitations 

NAND  flash  memory 
cannot  be  overwritten, 
but  has  to  be  rewritten 
to  previously  erased 
blocks.  If  a  software 
encryption  program 
encrypts  data  already  on 
the  SSD,  the  overwritten 
data  is  still  unsecured, 
unencrypted,  and 
accessible  (drive-based 
hardware  encryption 
does  not  have  this 
problem).  Also  data 
cannot  be  securely 
erased  by  overwriting 
the  original  file  without 
special  “Secure  Erase” 
procedures  built  into  the 
drive. 

HDDs  can  overwrite  data 
directly  on  the  drive  in  any 
particular  sector. 

Cost  per  capacity 

As  of  February  2011, 
NAND  flash  SSDs  cost 
about  (U.S.)$.90-2.00 
per  GB 

As  of  February  2011,  HDDs 
cost  about  (F1.S.)$0.05/GB  for 
3.5  in  and  $0.10/GB  for  2.5  in 
drives 
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Attribute  or 
characteristic 

Solid-state  drive 

Spinning  disk  drive 

Storage  eapaeity 

As  of  December  2011, 
SSDs  come  in  different 
sizes  up  to  2TB  but  are 
typically  not  larger  than 
64-256GB,  due  to  their 
high  cost  per  capacity. 

As  of  December  2011,  HDDs 
are  typically  up  to  1TB  in 
capacity  but  drives  up  to  4TB 
are  available. 

Read/write 

performance 

symmetry 

Less  expensive  SSDs 
typically  have  write 
speeds  significantly 
lower  than  their  read 
speeds.  Higher 
performing  SSDs  have  a 
balanced  read  and  write 
speed. 

HDDs  generally  have  slightly 
lower  write  speeds  than  their 
read  speeds. 

Free  block 
availability  and 

TRIM 

SSD  write  performance 
is  significantly  impacted 
by  the  availability  of 
free,  programmable 
blocks.  Previously 
written  data  blocks  that 
are  no  longer  in  use  can 
be  reclaimed  by  TRIM; 
however,  even  with 
TRIM,  fewer  free, 
programmable  blocks 
translates  into  reduced 
performance. 

HDDs  are  not  affected  by  free 
blocks  or  the  operation  (or 
lack)  of  the  TRIM  command 

Power  consumption 

High  performance  flash- 
based  SSDs  generally 
require  1/2  to  1/3  the 
power  of  HDDs;  High 
performance  DRAM 
SSDs  generally  require 
as  much  power  as 

HDDs  and  consume 
power  when  the  rest  of 
the  system  is  shut  down. 

High  performance  HDDs 
generally  require  between  12- 
18  watts;  drives  designed  for 
notebook  computers  are 
typically  2  watts. 

Table  1 .  Solid  State  Memory  Drives  vs.  Spinning  Disk  Memory  Drives 

(From  Wikipedia,  2012) 


27 


As  shown  in  Table  1,  spinning  disk  drives  are  much  more  affordable  than  their 
solid-state  counterparts,  in  terms  of  initial  acquisition  costs.  Solid  state  drives,  however, 
provide  far  more  performance  and  far  less  cost  once  acquired  due  to  the  reduction  in  the 
amount  of  physical  equipment  required.  This  is  highlighted  in  Figure  4,  the  Fusion-io 
comparison  of  a  SAN  based  VDI  versus  a  Fusion-io  SSD  system  (Fusion-io,  2011): 


System  Comparison 

SAN-BASED  SYSTEM  (44U  RACK  SPACE) 

I  •  SAN  (6U) 

•  15  X  2U  servers 

-  1 5  Fibre  Channel  HBAs 

•  2  X  2U  Fibre  Channel  switches 

•  2  X  2U  connection  brokers  (primary 
and  failover) 


V3  SYSTEM  (8U  RACK  SPACE) 

•  Only  user/archival  data  on  central  storage 

•  1  X  2U  V3  V-32 

•  1  X  2U  lOGbE  switch 

•  2  X  2U  connection  brokers  (primary 
and  failover) 

•  Vcenter  with  V3  Management 


Connection  Brokers  ''  ^ 

w 


Workstations 


Connection  Brokers 


Golden  images 
Clones 


Workstations 


Vcenter  with  V3  Management 
Manages  any  number  of  V3  appliances 


Figure  4.  SAN  Based  System  and  SSD  Based  System  Comparison 

(From  Fusion-io,  2011) 


Additionally,  the  performance  of  a  spinning  disk  drive  does  not  scale  linearly  like 


that  of  a  SSD.  To  increase  read  and  write  latency,  a  SSD  has  to  spin  faster.  The  head 
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actuator  that  moves  across  the  disk  does  not  move  faster  though.  So  by  spinning  a  drive 
50%  faster,  the  net  performance  increase  is  only  30%  (Siebert,  2011).  This  does  result  in 
higher  lOPS,  but  at  a  cost.  Having  to  spin  the  disk  at  such  a  high  rate  for  modest  returns 
will  lead  to  higher  than  normal  wear  on  the  disk,  which  will  require  an  earlier 

replacement.  SSDs  are  linear  in  their  performance  scalability,  which  makes  them  the 
better  candidate  for  an  organization  seeking  to  know  exactly  the  performance  and 
capability  they  will  receive  for  the  price. 

Organizations,  like  the  U.S.  Navy,  are  looking  to  get  the  most  bang  for  their  buck 
while  reducing  overhead.  In  the  ever  more  stringent  fiscal  environment,  the  U.S.  Navy 
and  others  need  to  be  able  to  track  exactly  where  their  expenditures  are  going.  SSDs  may 
provide  organizations  the  performance  they  want  from  their  VDIs.  At  the  same  time  all 
will  need  to  lower  overall  costs  through  a  reduction  in  physical  infrastructure.  SSDs 
make  financial  sense  when  compared  to  their  spinning-disk  counterpart. 

B,  HISTORY 

SSD  drives  first  made  an  appearance  in  the  1950s,  but  were  short  lived  as  the 
introduction  of  the  cheaper  drum  storage  units  replaced  them.  They  were  once  again 
used  in  the  1970s  and  1980s  in  conjunction  with  IBM,  Amdahl  and  Cray  super 
computers.  Their  extremely  high  costs  meant  that  they  were  rarely  used  and  were  once 
again  shelved  in  favor  of  cheaper,  more  readily  available  technologies.  SSDs  have 
sparsely  appeared  throughout  the  years  since.  All  have  been  unable  to  take  hold  until 
recently,  where  more  and  more  SSD  developers  have  finally  found  a  foothold  in  the 
marketplace  (Wikipedia,  2012). 

C.  THE  STATE  OF  SOLID  STATE  MEMORY 

Again,  the  concept  of  SSDs  and  its  benefits  are  not  new.  Just  now,  though,  the 
technology  is  reemerging  on  the  marketplace  in  quantities  and  prices  that  make  it  a  viable 
option  for  organizations.  The  performance  of  a  SSD  versus  that  of  a  spinning  disk  is  not 
exactly  one  to  one  which  made  it  hard  for  organizations  to  cross  examine  the  two 
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technologies.  Since  they  are  not  one  to  one  and  the  cost  of  spinning  disks  tends  to  be 
cheaper,  organizations  have  had  an  adverse  outlook  on  SSDs. 

When  looking  at  the  market  now,  SSDs  still  make  up  only  a  small  percentage  of 
storage  units  sold.  That  is  not  to  say  that  market  is  not  growing.  More  and  more 
developers  have  appeared  in  recent  years  than  there  has  ever  been  in  the  SSD  market.  The 
increased  numbers  of  developers  are  a  signal  that  there  is  a  market  for  the  product  as  the 
numerous  amounts  of  vendors  must  be  selling  their  products  to  someone.  Corporations 
such  as  Fusion-io,  the  largest  SSD  developer,  are  trading  publicly  on  the  stock  market 
with  more  SSD  companies  to  follow. 

D,  ADVANTAGES  OF  SOLID  STATE  MEMORY 

The  benefits  of  SSDs  for  VDIs  are  significant  according  to  Fusion-io,  and  include 
the  following  advantages: 

•  The  ability  to  support  a  greater  number  of  virtual  desktops  per  virtual 
server  than  spinning  media.  (Fusion-io,  2011) 

•  Can  guarantee  performance  even  during  peak  loads  due  to  the  ability  to 
sustain  high  lOPS  rates.  (Fusion-io,  2011) 

•  Provides  low  latency  for  faster  end  user  desktop  experiences.  (Fusion-io, 

2011) 

•  Will  make  VDl  cost-effective  enough  to  localize  servers  and  eliminate 
network  latency.  (Fusion-io,  2011) 

•  Reduce  reliance  on  expensive,  complex  external  storage.  (Fusion-io,  2011) 

•  Will  lower  the  overall  cost  per  desktop  while  providing  higher 
performance.  (Fusion-io,  2011) 

E,  SOLID  STATE  MEMORY  AND  THE  USN/USMC 

As  the  Navy  and  Marine  Corps  looks  to  expand  joint  proficiencies  through 
improved  computing  capabilities,  these  capabilities  must  prove  to  perform  better  than 
what  is  currently  in  use,  must  drastically  expand  mission  capabilities,  and  do  so  for  a  cost 
that  is  reasonable  or  justifiable.  The  Department  of  Defense  is  loath  to  throw  money  at 
technology  that  only  provides  singular  mission  capabilities  or  limited  improvements.  For 
new  technology  to  be  considered  for  acquisition  by  the  DoD,  it  must  offer  multiple 
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mission  capability  improvements.  VDI  in  conjunction  with  solid  state  drives  can  provide 
Naval  and  Marine  units  improved  eomputing  eapabilities  that  open  up  a  world  of 
possibilities  in  terms  of  joint  mission  tasking.  Alone,  solid  state  drives  provide  many 
performance  improvements  in  terms  of  computing  but  also  provide  many  fringe  benefits 
that  are  of  value  to  Naval  and  Marine  units  that  makes  them  a  eompelling  new 
technology  that  is  worth  investing  in. 

In  terms  of  performance  improvements,  solid  state  drives  provide  many  eompared 
to  spinning  disks.  SSDs  provide  faster  spin  up  times,  faster  data  transfer  rates,  quieker 
random  aceess  times,  and  improved  read  lateney  times.  When  utilized  within  a  VDI, 
these  improvements  quiekly  add  up  to  real  world  capabilities.  Virtual  desktops  using 
produets  like  Fusion-io  drives  can  provide  the  end  user  with  a  desktop  that  rivals  high 
end  desktops.  Figure  5  eompares  the  times  for  a  virtual  desktop  using  Fusion-io’s  solid 
state  drives  to  complete  common  computing  tasks  compared  to  a  loeal  desktop  (Fusion- 
io,  2011). 
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Figure  5. 


Virtual  Desktop  Utilizing  SSD  vs.  Loeal  Desktop  (Fusion-io,  2011) 


The  performanee  improvements  are  elear  when  put  side  by  side.  These  desktops 
can  be  instantly  ereated  or  removed  as  needs  arise  providing  amphibious  vessels 
additional  flexibility  in  joint  missions.  This  allows  for  disparate  organizations  and 
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personnel  to  embark  Naval  Amphibious  vessels  and  be  given  high  quality  desktop 
without  the  expense  or  overhead  of  loeal  desktops.  Also,  eonsidering  a  VDI  can  support 
tens  to  hundreds  of  virtual  desktops,  the  cost  savings  are  clear. 

Solid  state  drives  not  only  improve  the  capabilities  of  an  amphibious  vessel’s  VDI 
but  also  provide  many  other  improvements  in  terms  of  cost  and  performance.  Solid  state 
drives  require  far  less  power  than  spinning  disk  drives.  “High  performance  flash-based 
SSDs  generally  require  1/2  to  1/3  the  power  of  spinning  disk  drives”  (Wikipedia,  2012). 
Solid  state  drives  also  require  far  less  hardware  which  means  that  far  less  power  is  used 
to  run  the  system  and  to  run  support  equipment  such  as  cooling  systems.  Any  reduction  in 
power  consumption  onboard  naval  vessels  is  of  a  high  value  as  power  at  sea  equals  fuel 
usage. 

Solid  state  drives,  as  their  name  implies,  do  not  have  any  moving  parts.  Without 
moving  parts  to  break,  mechanical  reliability  increases.  This  leads  to  costs  savings  in 
both  re-acquisition  and  as  well  as  in  man-hours  required  to  fix  or  replace  broken  drives. 
This  allows  manpower  to  be  reduced  or  reassigned  to  where  it  is  needed  which  improves 
overall  mission  capability. 

With  no  moving  parts,  solid  state  drives  have  far  lower  acoustic  levels.  Although 
the  amount  of  sound  emitted  by  spinning  drives  may  negligible  in  real  world  applications, 
any  reduction  in  sound  levels  of  equipment  aboard  ships  is  applicable.  Sound  emitted 
from  equipment  on  board  naval  vessels  is  cumulative  and  all  adds  to  the  overall  sound 
signature.  Any  reduction  in  sound  levels  of  equipment  aboard  a  Naval  vessel  will  lead  to 
the  overall  reduction  in  the  sound  signature  of  the  vessel. 

Another  concern  in  the  naval  environment  is  shock  and  vibration.  Naval  vessels 
are  susceptible  to  shock  and  vibration  from  equipment  onboard,  sea  states,  and  in  some 
cases  battle  damage.  Due  to  the  lack  of  moving  parts  in  solid  state  drives,  they  are  far 
less,  if  at  all,  susceptible  to  vibration  or  shock  damage  caused  by  detonations  and 
explosions.  This  is  another  factor  that  improves  the  reliability  of  an  amphibious  vessel’s 
VDI  which  in  turn  reduces  cost  and  man-power  requirements. 
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IV.  AMPHIBIOUS  NETWORK  INTEGRATION  ANALYSIS 


A.  OVERVIEW 

Initial  observations  of  this  LAN  integration  proeess  began  over  four  years  ago 
with  the  mentioned  15th  MEU  re-embarkation,  where  inorganic  workstation  integration 
was  witnessed  first-hand.  Those  experienced  practices  were  bolstered  through  additional 
observations  made  from  later  interactions  with  multiple  Expeditionary  Strike  Groups 
(ESGs)  and  Amphibious  Readiness  Group  (ARGs).  Most  recently,  a  draft  of  the  AS-IS 
architecture  was  refined  and  confirmed  to  be  accurate  onboard  USS  WASP  (EHD-1) 
during  Trident  Warrior  1 1 . 

The  purpose  of  this  chapter  is  to  apply  observations  toward  a  notional  analysis  of 
the  LHD  workstation  integration  process  in  effort  to  conceptually  identify  areas  of 
improvement  and  form  feasible  technology  and  architecture  recommendations.  The 
approach  is  guided  from  NPS  IS4220  and  IS4250  course  discussions  based  upon  an 
Enterprise  Architecture  Integration  Case  Study,  in-class  exercises,  and  individual  product 
examples  provided  from  the  instructor.  The  following  structure  is  leveraged  for  the 
model: 

1.  Define  current  view  of  EHD  LAN  Integration 

2.  Define  core  integration  processes  and  organizing  logic 

3.  Current  Processes 

4.  Generalizations  for  Modeling 

1.  Current  View  Defined 

The  AS-IS  Enterprise  Architecture  used  onboard  amphibious  flagships  has  grown 
overwhelmingly  with  noted  compliance  policies.  Eunctional  personnel  supporting 
network  integration  are  separately  tasked  and  functional-to-functional  interaction  has 
evolved  into  bottlenecking  reciprocal  relationships.  Individual  workstations  must 
separately  travel  to  functional  areas,  each  with  tedious  and  time-consuming  compliancy 
requirements.  Eor  example,  a  computer  must  be  delivered  to  one  workspace  for  hardware 
compliance  validation,  another  for  operating  system  verification,  and  yet  another  for 
security  update  confirmations.  In  practically  every  instance,  each  workstation  will  not 
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meet  any  Navy  afloat  standards,  requiring  a  eomplete  hard  drive  sliek,  0/S  re-imaging, 
and  comprehensive  security  patch  update  conducted.  Additional  areas  for  improvement 
within  the  current  architecture  are: 

•  Strict  reliance  on  limited  IT21  afloat  approved  hardware 

•  Inflexibility  on  specific  version  of  0/S  and  ship  network  version  image 

•  Requisite  lengthy  security  scanning  and  updating  durations 

•  Separation  of  functional  area  assets  and  capabilities 

•  Physical  change  of  custody  of  workstation  to  ship 

•  Waiting  time  of  functional  areas  in  reciprocal  workstation  processing 

Overall,  amphibious  ships’  IT  crew  continuously  integrate  MEU,  squadron,  staff, 
and  individual  workstations  requesting  network  services  for  underway  and  destination 
use.  The  functional  personnel  and  processes  dogma  is  so  ingrained  that 
customers/embarkees  become  lulled  into  an  acceptance  of  high  military  standard 
compliance,  even  in  the  context  of  unclassified  or  publically  accessible  work.  In 
situations  where  rapid  action,  crisis  response,  or  disaster  relief  call  for  immediate 
integration  and  critical  planning,  the  present  architecture  becomes  unacceptable  and  core 
processes  are  called  into  high  visibility  with  direct  questioning.  Occasionally,  what  was 
once  mandatory  becomes  compromised  and  temporarily  modified  to  fit  tighter 
operational  timelines.  Through  identifying  and  defining  what  exactly  is  core  to 
workstation  integration  from  a  ship-hosting  enterprise  network  perspective,  an 
understanding  of  process  integration  and  standardization  contributing  to  overall 
improvement  becomes  visible. 

2.  Core  Processes  and  Organizing  Logic  Defined 

Observed  network  integration  practices  were  captured  through  Business  Process 
Modeling  techniques.  After  an  initial  introduction  to  functional  personnel,  the 
workstation  integration  process  is  described. 

Stated  observation  and  fleet  verification  identified  five  groups  of  core  personnel 
supporting  network  integration:  Joint  Network  Operations  Center  (JNOC),  Data  System 
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Repair  (DSR),  Automated  Data  Processing  (ADP),  Information  Assurance  (lA),  and 
USMC  Information  Technology  (IT)  Quality  Assurance  (QA).  Onboard  amphibious 
command  ships,  JNOC  members  serve  roles  as  customer  support,  receiving  requests  and 
managing  their  resolution,  and  System  Administrators  (SAs)  to  the  network  servers. 
DSR  personnel  are  responsible  for  the  operation  of  the  network  infrastructure,  consisting 
of  the  physical  connections  of  servers  through  backbone  and  edge  switches  and  finally 
drops  within  the  space.  Also,  DSR  provides  some  limited  capability  for  trouble-shooting 
and  repairing  IT  hardware.  Next,  the  lA  team  ensures  all  onboard  IT  hardware  and 
software  configuration  and  operation  meet  DoD,  Navy,  and  ship  security  policy.  Finally, 
USMC  QA  represents  the  embarking  organization’s  IT  personnel  holding  comparable 
training  and  knowledge  to  their  previously  mentioned  Navy  counterpart  groups;  however, 
embarkees  typically  focus  on  the  end  result,  an  operable  workstation  on  the  provided 
network. 


3.  Current  Process 

As  experienced  in  the  Fleet,  our  AS-IS  process  model  can  be  best 
described  as: 

a)  JNOC  receives  a  request  to  integrate  a  quantified  number  of  workstations 
onto  the  ship’s  network.  Servers  are  checked  to  verify  if  the  capacity 
exists  to  host  the  requested  user  profiles  and  manage  the  connected 
workstations.  Overall  count  is  determined  and  DSR  validates  if  the 
network  infrastructure  can  support  the  workstations  at  the 
requested/assigned  ship  space.  When  the  server  and  infrastructure 
capacities  are  negotiated,  JNOC  is  able  to  take  inventory,  often 
transferring  possession  to  themselves,  of  the  workstations.  This  process  is 
illustrated  in  Figure  6. 
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Figure  6.  Amphibious  LAN  Integration  Step  a) 


b)  ADP  initially  eonfirms  that  the  workstation  is  functional.  If  not,  either  the 
embarking  IT  personnel  or  DSR  have  an  opportunity  to  trouble-shoot  and 
fix  the  computer.  If  operational,  the  image  is  checked  to  ensure  it 
complies  with  the  exact  shipboard  network  image.  In  nearly  all  cases 
policy  requires  the  workstation  to  be  slicked,  re-imaged,  and  loaded  with 
the  most  recent  version  of  applicable  Operating  System  (0/S).  The  lA 
team  then  loads  each  workstation  with  the  appropriate  software  and 
patches  to  ensure  overall  security  compliance.  This  process  is  illustrated  in 
Figure  7. 
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Any  member  of  ADP  Any  mer 


Figure  7.  AS-IS  Amphibious  LAN  Integration  Step  b) 


c)  JNOC  delivers  the  workstation  to  its  assigned  space  and  DSR  enables  the 
specific  port  on  the  switch  that  is  wired  to  the  drop.  Occasionally,  the  port 
and  drop  link  is  not  initially  operational  and  requires  some  trouble¬ 
shooting  by  DSR  to  achieve  network  connectivity.  This  process  is 
illustrated  in  Figure  8. 
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Figure  8.  AS-IS  Amphibious  LAN  Integration  Step  e) 

d)  Finally,  USMC  QA  performs  their  overall  functionality  check  on  each 
workstation  with  an  appropriate  user  where  integration  is 
ultimately  confirmed. 

4,  Generalizations  for  Modeling 

To  design  and  model  the  analyzed  integration  process,  the  following 
generalizations  were  required; 

a.  Sub-Process  Duration 

Each  modeled  activity  consisted  of  estimated  times  to  complete.  Again, 
previous  tours  experience  managing  the  actual  sub-processes  allowed  averages  to  be 
applied.  Activity  durations  were  further  reviewed  and  agreed  upon  by  current  WASP  IT 
leadership,  as  well. 

b.  Decision-Point  Probability 

At  distinct  points  throughout  the  process,  probabilities  had  to  be 

incorporated  to  represent  various  realities  to  the  modeled  environment.  Thresholds  to 

servers  and  switch  capacity  often  do  not  reach  full  visibility  until  each  embark  is 
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requested.  Additionally,  equipment  onboard  and  brought  from  various  loeations  often  is 
transported  and  operates  in  eonditions  exeeeding  manufacturers’  recommendations.  As  a 
result,  workstations/IT  equipment  and  their  components  fail  before  their  anticipated  end 
of  life  cycle. 


c.  Volume  of  Integration 

Embarkations  may  vary  from  individuals,  to  staffs,  and  Marine 
Expeditionary  Elnits  (MEEls).  Designed  to  embark  MEEls,  amphibious  ship  networks  and 
their  supporting  processes  are  only  flexed  when  a  full  complement  of  Marines  are 
onboard.  Our  current  model  is  best  served  representing  an  integration  of  300 
workstations  typically  requested  by  the  MEEl  for  the  ship’s  ETNCEAS  network. 

d.  Associated  Costs 

The  current  MEU  UNCEAS  workstation  integration  process  is  only  one  of 
a  multitude  while  beginning  an  underway  period,  transit,  of  a  deployment.  The  litany  of 
preparations  to  get  underway  has  both  Sailors  and  Marines  pulled  in  several  directions. 
As  observed,  two  members  from  each  group  are  able  to  support  this  process  during  a 
workday.  Each  is  required  to  have  the  capabilities  expected  of  an  E-5  in  their  IT 
specialty.  Our  cost  is  measured  based  upon  this  analysis.  The  AS-IS  amphibious  LAN 
integration  metrics,  including  cost  and  number  of  people,  developed  by  the  authors  are 
depicted  in  Table  2. 
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Simulation  Results 


Duration  121:00:15Tlme 


Process  Time  And  Cost 

Priicess  SonariD 

iRStanos 

Total  Cost 

Waiting  The  (Tine) 

ToblTIne^ne) 

Matthias Becker 6ruberVl Vl 0  (default) 

300 

13504.6 

22548:51:30 

15428:04:45 

R^uice 

Unit 

Cost/Unit 

#Pe<wie 

Utilization 

Any  member  of  ADP 

Hour 

16,66 

2.00 

264.60% 

Any  member  ofDSR 

Hour  ' 

1  '  16.66 

2.00 

430.60% 

Any  member  oflA 

Hour 

16.66 

2.00 

229.96% 

Any  member  ofJNOC 

Hour 

16.66 

2.00 

210.92% 

Any  member  ofUSMCQA 

Hour 

16,66 

2.00 

79.69% 

Table  2.  AS-IS  Amphibious  LAN  Integration  Metrics 


Running  several  simulations,  the  results  given  in  Table  2  were  found  to  be 
typical.  The  results  shown  in  Table  2  realistically  portrayed  outcomes  in  alignment  with 
our  experiences  and  several  Navy  and  Marine  IT  support  staff  input.  Total  duration  of 
300  MEU  NIPR  workstations  integration  lasted  over  15  days,  accurately  reflecting 
mentioned  embarkations.  Also,  acceptable  utilization  of  personnel  should  be  less  than 
80%  of  their  workday,  calculating  in  other  tasking  and  breaks.  The  business  processes 
used  onboard  LHD’s  causes  IT  staff,  characteristic  to  this  platform,  to  be  over- worked 
during  MEU  embarks  upwards  of  5  times  what  is  considered  reasonable  utilization. 

The  cursory  knowledge  of  the  core  personnel  and  current  business 
processes  of  network  integration  allows  for  a  foundation  of  organizing  logic.  Process 
integration  and  standardization  are  then  prioritized  to  provide  requirements  for  a  TO-BE 
EA.  The  AS-IS  model  clearly  enforces  high  standardization  and  low  business  process 
integration.  Both  hardware  and  software  must  be  manipulated  to  ensure  the  standard 
infrastructure  integrity  is  upheld.  High  replication  practices  left  no  room  for  coordination 
efforts  of  nearly  every  other  military  and  government  entity  besides,  specifically,  a 
Marine  Expeditionary-budgeted  force  with  equipment  expressed  designed  for  the 
platform  they  are  embarking. 
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Given  today’s  broad  Range  of  Military  Operations  (ROMO),  the  current 
organizing  logic  becomes  unsuitable.  Rather,  a  balanced  combination  of  both 
Coordination  and  Replication  are  necessary.  Leveraging  the  two,  outside  disparate 
organizations  need  to  become  unified  beginning  with  the  shipboard  LAN/enterprise,  into 
a  single  business,  to  support  the  combined,  collaborative  operational  and  decision-making 
processes  demanded  from  today’s  challenges.  Although  technology  alone  should  never 
be  an  absolute  solution,  it  can  be  successfully  partnered  with  some  process  re¬ 
engineering.  The  targeted  architecture  involves  an  upward  movement  toward  higher 
process  integration  to  obtain  unification. 
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V.  TRIDENT  WARRIOR  2011  EXPERIMENTATION 


A.  TRIDENT  WARRIOR  DESCRIPTION 

Gaps  in  operational  needs  and  the  realities  of  enterprise  planning  are  not  held 
within  dialogues  between  afloat  eommanders  and  their  onboard  eaptive  audienees. 
Feedbaek  from  deployed  Strike  Group  and  ARG  lessons  learned  are  routinely  eaptured, 
reviewed,  and  forwarded  through  their  respective  chains  of  command  to  a  higher, 
ultimately.  Component  Command.  Component  Commands,  in  turn,  are  tasked  with 
anticipating  and  appropriately  manning,  training,  and  equipping  their  operational  units  to 
effectively  meet  desired  Mission  Essential  Tasks  (METs)  across  multiple  warfare 
domains.  Obtaining  operational  responsiveness  and  relevance  requires  venues  supporting 
near-term  and  developmental  inquiries  into  improving  each  aspect  of  manning  levels, 
personnel,  team,  and  command  training,  and  technology  available.  One  means  for 
addressing  voiced  challenges  or  closing  gaps  is  through  experimentation  onboard  within 
an  operationally  simulated  environment. 

Recently,  U.  S.  Elect  Eorces  Command  (EEC),  a  Component  Commander  for  the 
Navy’s  Atlantic  theater,  directed  TWll  to  be  conducted  primarily  within  Elect  while 
coordinating  efforts  and  sponsorship  with  5th  Elect.  "Trident  Warrior  (TW)  is  an  annual 
fleet  experiment  designed  to  improve  war  fighting  policies  and  capabilities  by  providing 
answers  to  detailed  analytical  questions  about  more  than  50+  critical  maritime  initiatives 
included  in  the  experiment’s  execution’’  (EEC  TW,  2011).  TW  team  members  are  highly 
skilled  in  structuring,  executing,  and  analyzing  research  initiatives  requested  from  the 
deckplates,  addressing  urgent  needs,  to  enterprise  inquiries  on  future  capabilities. 
Notably,  TW  is  able  to  create  initiatives  for  ship’s  company  personnel  to  be  integral 
research  participants  within  interactive  experimentation  and  data  collection.  TW  final 
reports  warrant  the  highest  visibility  and  effectively  grant  a  peek  at  the  possible  for 
decisions  made  impacting  the  next  Strike  Group’s  deployment  or  shaping  strategies. 

Erom  August  until  September  2011,  the  leadership  and  bulk  of  the  TWll  team 
embarked  aboard  U.S.S.  WASP  (EHD-1)  to  conduct  experiments  spanning  the  full  range 
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of  warfare  areas.  The  whole  of  their  assigned  initiatives  incorporated  emerging 
technologies  to  enhance  the  processes  and  operations  that  maritime  forces  currently 
practice.  Additionally,  the  Trident  Warrior  process  has  the  ability  to  introduce 
capabilities  that  could  develop  new  Tactics,  Techniques,  and  Procedures  (TTPs)  for  the 
U.S.  Navy.  Rallying  on  FORCENet  Innovation  and  Research  Enterprise’s  (EIRE)  portal 
and  database  resources,  TWll  organized  their  experimental  objectives,  resulting 
planning,  assessments,  respective  analysis,  and  results.  Each  critical  initiative  was 
grouped  into  seven  focus  areas:  Command  and  Control  (C2),  Electronic  Warfare 
(EW)/Eires,  Information  Operations  (10),  Information  Technology  (IT),  Information 
Surveillance  and  Reconnaissance  (ISR),  Missile  Defense,  and  Networks  (NET). 

B  TRIDENT  WARRIOR  THREAD  NET  1 1,01 

One  Networks  focus  area  thread,  identified  as  NET  11.01,  directly  aligned  with 
the  purpose  of  this  thesis.  Titled  as  Next  Generation  Technologies  (NGT)  Virtual 
Infrastructure  for  embarkables,  NET  II.OI’s  single  objective  question  asked,  “Can  [a] 
NGT  virtual  desktop  infrastructure  (VDI)  client  serve  as  an  intermediary  to  interface 
NMCI  workstation  client  to  [an]  IT-21  network  to  provide  IT-21  applications  and 
services  (e.g.,  IT-21  patches)  for  an  embarked  NMCI  machine  (capable/usable)?”  (EEC 
TW,  2011).  In  short,  the  experimentation  thread  inquired  if  VDI  could  provide  a  bridge 
from  a  hosting  ship’s  network  to  embarking  workstations.  The  ship’s  network  and 
operating  system,  IT-21  and  COMPOSE  (Common  PC  Operating  System  Environment) 
respectively,  and  the  simulated  embarking  NMCI  workstations  all  represent  the  most 
stringent  requirements  for  network  integration.  As  an  objective  for  experimentation, 
TWll  sought  to  “demonstrate  NGT’s  ability  to  provide  a  variety  of  improved  network 
services”  (EEC  TW,  2011). 

C.  NET  11.01  TESTING 

Of  note,  the  Network’s  thread  specifically  keyed  more  into  VDI  technology 
functional  capabilities  than  the  processes  supporting  integration.  The  preceding  and 
following  chapters  provide  in  depth  observations  and  recommendations  regarding 
workstation  integration  processes.  Onboard  WASP,  NET  ll.Ol’s  intent  was  to  test  the 
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underway  performance  of  NGT  with  a  nominal  IT  infrastructure,  or  Common  Computing 
Environment  (CCE),  while  conducting  desktop  virtualization.  Simulating  the  nominal 
and  scalable  infrastructure,  TW  technical  representatives  mounted  an  IBM  HS-22  blade 
server  within  WASP’s  JNOC  opposed  to  the  standard  HS-21  blade  server,  typical  to  the 
location  of  IT-21  servers  on  LHDs.  Eor  reference,  the  specifications  and  structure  of  HS- 
22  servers  are  illustrated  in  Eigures  9  and  10  (IBM,  201 1,  p.  8  and  13).  The  specifications 
and  structure  of  HS-21  servers  are  illustrated  in  Eigures  11  and  12  (IBM,  2007,  p.  6  and 
10). 


Microprocessor:  Supports  up  to  two 

multi-core  Intel  Xeon  microprocessors. 

Note:  Use  the  Setup  utility  to 

determine  the  type  and  speed  of  the 

microprocessors  in  the  blade  server. 

Memory: 

•  12  dual  inline  memory  module 
(DIMM)  connectors 

•  Type:  Very  Low  Profile  (VLP) 
double-data  rate  (DDRS)  DRAM. 
Supports  1  GB,  2  GB,  4  GB,  8  GB, 
and  16  GB  DIMMs  with  up  to  192 
GB  of  total  memory  on  the  system 
board 

Integrated  functions: 

•  Horizontal-compact-form-factor 
(CFFh)  expansion  card  interface 

•  Vertical-combination-I/O  (CIOv) 
expansion  card  interface 

•  Local  service  processor;  Integrated 
Management  Module  (IMM)  with 
Intelligent  Platform  Management 
Interface  (IPMI)  firmware 

•  Integrated  Matrox  G200eV  video 
controller 

•  LSI  1064E  SAS  controller 

•  Broadcom  BCM5709S  dual-port 
Gigabit  Ethernet  controller 

•  Integrated  keyboard/video/mouse 
(cKVM)  controller  through  IMM 

•  Light  path  diagnostics 

•  RS-485  interface  for  communication 
with  the  management  module 

•  Automatic  server  restart  (ASR) 

•  USB  2.0  for  communication  with 
cKVM  and  removable  media  drives 
(an  external  USB  port  is  not 
supported) 

•  Serial  over  LAN  (SOL) 

•  Redundant  buses  for 
communication  with  keyboard, 
mouse,  and  removable  media 
drives 


Predictive  Failure  Analysis  (PFA) 

alerts: 

•  Microprocessors 

•  Memory 

•  Storage  drives 

Electrical  input:  12  V  dc 

Environment: 

•  Air  temperature: 

-  Blade  server  on:  10°C  to  35°C 
(50°F  to  95°F).  Altitude:  0  m  to 
914.4  m  (0  ft  to  3000  ft) 

-  Blade  server  on:  10“C  to  32“C 
(50"F  to  89.6°F).  Altitude:  914.4 
m  to  2133.6  m  (3000  ft  to  7000 
ft) 

-  Blade  server  off:  10°C  to  43°C 
(50°F  to  109.4°F).  Altitude:  914.4 
m  to  2133.6  m  (3000  ft  to  7000 
ft) 

-  Blade  server  shipping:  -40°C  to 
60“C  (-40°F  to  140“F) 

•  Humidity: 

-  Blade  server  on:  8%  to  80% 

-  Blade  server  off:  8%  to  80% 

-  Blade  server  storage;  5%  to  80% 

-  Blade  server  shipment:  5%  to 
100% 

•  Particulate  contamination: 
Attention:  Airborne  particulates 
and  reactive  gases  acting  alone  or 
in  combination  with  other 
environmental  factors  such  as 
humidity  or  temperature  might 
pose  a  risk  to  the  server.  For 
information  about  the  limits  for 
particulates  and  gases,  see 

I  Particulate  contamination"  or| 

page  85. 


Drives:  Supports  up  to  two  hot-swap, 
small  form  factor  (SFF)  Serial  Attached 
SCSI  (SAS)  or  Serial  ATA  (SATA) 
storage  drives 

Size  (Type  7870  and  Type  1936): 

•  Height:  24.5  cm  (9.7  inches)  (6U) 

•  Depth:  44.6  cm  (17.6  inches) 

•  Width;  2.9  cm  (1.14  inches) 

•  Maximum  weight:  4.8  kg  (10  lb) 

Size  (Type  1911): 

•  Height:  24.5  cm  (9.7  in) 

•  Depth;  44.6  cm  (17.6  in) 

•  Width:  14.5  cm  (5.71  in) 

•  Maximum  weight:  8.15  kg  (40.02  lb) 

NEBS  Environment 

•  Air  temperature; 

-  Blade  server  on:  5“C  to  40°C  (41  °F 
to  104°F).  Altitude:  -60  m  to  1800 
m  (-197  ft  to  6000  ft) 

-  Blade  server  on:  5“C  to  30“C  (41  “^F 
to  86°F).  Altitude:  1800  m  to  4000 
m  (6000  ft  to  13000  ft) 

-  Blade  server  off:  -5°C  to  55°C 
(23°F  to  131°F).  Altitude;  -60  m  to 
1800  m  (-197  ft  to  6000  ft) 

-  Blade  server  off:  -5°C  to  45°C 
(23"F  to  113"F).  Altitude;  1800  m 
to  4000  m  (6000  ft  to  13000  ft) 

-  Blade  server  storage:  -40°C  to 
60°C  (-40°F  to  140°F) 

•  Humidity:  8%  to  85% 

•  Particulate  contamination: 

Attention:  Airborne  particulates 
and  reactive  gases  acting  alone  or  in 
combination  with  other 
environmental  factors  such  as 
humidity  or  temperature  might  pose 
a  risk  to  the  server.  For  information 
about  the  limits  for  particulates  and 
gases,  see  ''Particulate 
contamination"  on  page  85. 


Eigure  9.  HS-22  Blade  Server  Speeifieations  (Erom  IBM,  201 1,  p. 
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Figure  10.  HS-22  Major  Components  (From  IBM,  2011,  p.  13) 
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Microprocessor:  Supports  up  to  two 
dual-  or  quad-core  Intel®  Xeon 
microprocessors. 

Note:  Use  the  Configuration/Setup 
Utility  program  to  determine  the  type 
and  speed  of  the  microprocessors  in 
your  blade  server. 

Memory: 

•  Dual-channel  DIMMs:  4  DIMM  slots 

•  Type:  fully-buffered  double-data 
rate  (FB-DDR2),  PC2-5300,  ECC 
SDRAM  registered  x4  (Chipkill) 
DIMMs 

•  Supports  512  MB,  1  GB,  2  GB,  and 
4  GB  DIMMs  (as  of  the  date  of  this 
publication)  with  up  to  16  GB  of 
total  memory  in  the  system  board 

•  Additional  memory  support  when  an 
optional  IBM  BladeCenter  Memory 
and  I/O  Expansion  Blade  is 
installed 

Drives:  Support  for  up  to  two  internal 
small-form-factor  Serial  Attached  SCSI 
(SAS)  drives 

Predictive  Failure  Analysis®  (PFA) 
alerts: 

•  Microprocessor 

•  Memory 

•  Hard  disk  drives 

Electrical  Input:  12  V  dc 


Integrated  functions: 

•  Dual  Gigabit  Ethernet  controllers 

•  Expansion  card  interface 

•  Local  service  processor: 
Baseboard  management  controller 
(BMC)  with  Intelligent  Platform 
Management  Interface  (IPMI) 
firmware 

•  ATI  RN-50  ESI 000  video 
controller 

•  LSI  1064E  Serial  Attached  SCSI 
(SAS)  controller 

•  Light  path  diagnostics 

•  RS-485  interface  for 
communication  with  the 
management  module 

•  Automatic  server  restart  (ASR) 

•  Serial  over  LAN  (SOL) 

•  Redundant  buses  for 
communication  with  keyboard, 
mouse,  and  removable  media 
drives 

•  Concurrent  keyboard/video/mouse 
(cKVM)  support  when  optional 
cKVM  feature  card  is  installed 

Environment  (non-NEBS): 

•  Air  temperature: 

-  Blade  server  on:  10°  to  35°  C 
(50°  to  95°  F).  Altitude:  0  to 
914  m  (0  to  3000  ft) 

-  Blade  server  on:  10°  to  32°  C 
(50°  to  90°  F).  Altitude:  914  to 
2134  m  (3000  to  7000  ft) 

-  Blade  server  off:  -40°  to  60°  C 
(-40°  to  140°  F) 

•  Humidity: 

-  Blade  server  on:  8%  to  80% 

-  Blade  server  off:  5%  to  80% 


Environment  (NEBS): 

•  Air  temperature: 

-  Blade  server  on:  5°  to  40°C  (41° 
to  104°F).  Altitude:  -60  to  1800  m 
(-1 97  to  5905  ft) 

-  Blade  server  on  (short  term):  -5° 
to  55°C  (23°  to  131°F).  Altitude: 
-60  to  1800  m  (-197  to  5905  ft) 

-  Blade  server  on:  5°  to  30°C  (41° 
to  86°F).  Altitude:  1800  to  4000  m 
(5905  to  13  123  ft) 

-  Blade  server  on  (short  term):  -5° 
to  45°C  (23°  to  113°F).  Altitude: 
1800  to  4000  m  (5905  to  13  123 
ft) 

-  Blade  server  off:  -40°  to  60°C 
(-40°  to  140°F) 

•  Humidity: 

-  Blade  server  on:  8%  to  85% 

-  Blade  server  on  (short  term):  5% 
to  90%  but  not  to  exceed  0.024 
kg  water/kg  of  dry  air 

-  Blade  server  off:  uncontrolled 

Note:  “Short  term”  refers  to  a  period  of 
not  more  than  96  consecutive  hours 
and  a  total  of  not  more  than  1 5  days  in 
1  year.  (This  refers  to  a  total  of  360 
hours  in  any  year,  but  no  more  than  15 
occurrences  during  that  1-year  period.) 

Size: 

•  Height:  24.5  cm  (9.7  inches) 

•  Depth:  44.6  cm  (17.6  inches) 

•  Width:  2.9  cm  (1 .14  inches) 

•  Maximum  weight:  5.4  kg  (12  lb) 


Figure  11.  HS-21  Blade  Server  Speeifieations  (IBM,  2007,  p.  6) 
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.-•SAS  hard  disk  drives 


Figure  12.  HS-21  Blade  Server  Major  Components  (From  IBM,  2007,  p.  10) 


The  blade  servers  were  loaded  with  VMware  vSphere  ESX  4.1  and  View  4.6,  software 
produets  that  allow  virtual  infrastructures,  desktops,  and  their  pertinent  applications.  As 
an  additional  enhancement  to  the  tested  NOT  VDl,  a  Fusion-10  PCI  card  was  connected 
providing  storage  support  to  the  blade  servers  as  illustrated  in  Figure  13  (FIRE,  2011). 


NET  11.2  -  NGT  VDl 
SV2 


View  Connection 
Server 


WSUS  Server 


Net  1 1 .2  NGT  VDl  SV2  (Erom  EIRE,  2011) 
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Eigure  13. 


Once  the  physieal  infrastructure  was  in  place,  TW 1 1  Network  technicians  built  a 
virtualized  infrastrueture,  two  groups  of  virtual  desktops  associated  with  physieal  space 
locations  (WASP’s  Engineering  Log  Room  and  the  LFOC),  and  loaded  applications 
familiar  to  typical  onboard  users.  Within  each  assigned  physieal  space,  TW  NMCI 
workstations  running  both  Windows  XP  and  7  were  eonneeted  to  the  NOT  blade  servers 
through  an  embarked  NOT  switeh.  Each  NMCI  workstation  was  loaded  with  a  VMware 
virtual  elient  that  provided  the  virtualized  IT-21  COMPOSE  desktop.  Funetionality  tests 
were  eondueted  eovering  typical  workday  application  usage  and  windows  updating. 
WASP  erewmembers  who  were  surveyed  responded  positively  to  NET  ll.Ol’s  observed 
performanee  as  eaptured  in  Figure  14. 


Performance  Acceptable  for  Collec  ... 

Performar>ce  Degradation  (Compared  ... 

WSUS  Update'Patches 

Local  print! r>g 

Internet  Workir>g 

Word  Working 

Ourtlook  Workir>g 

Pov.erPoint  \*'/orkir>g 


0  2  4  6  8  10  12  14  16  18 

Figure  14.  Net  1 1.01  Trident  Warrior  Survey  Results 


I  Yes| 


Satisfying  the  nominal  afloat  workday  funetionality  experiment  requirements,  the 

TWll  Networks  Foeus  Area  Lead  allowed  for  additional  testing  to  be  accomplished. 

Teehnical  representatives  onboard  resonated  with  the  challenges  of  network  integration 

and  were  open  to  establishing  seenarios  geared  toward  improvementing  the  observed 

proeess.  Of  the  administration  and  life  cyele  management  benefits  VDI  presents,  the 

NET  11.01  Final  Test  Report  also  reeognizes  ease  of  deployment.  For  instance,  the 
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embarked  NGT  VDI  servers  and  network  was  installed  within  a  working  day!  From  a 
pre-existing  VDI,  ship-hosted  perspeetive,  further  seenarios  demonstrated  the  eapability 
of  ereating  hundreds  of  virtual  elients  in  a  few  minutes. 

Final  testing  for  the  TWll  underway  period  eonsisted  of  performanee 
eomparisons  of  the  blade  servers’  eonfiguration.  Neworks  Foeus  Area  idenitified 
managebility  as  elemental  to  VDFs  operational  funetionality.  IBM’s  HS-22  blade 
servers’  performance  creating  and  managing  clients  was  limited  to  the  hardware  brought 
onboard  WASP.  Scalabilty  of  the  servers  to  provide  for  a  typical  MEU  deployment 
approached  costs  that  seemed  unfeasible.  Off-the-shelf,  HS-22s  could  provide  the 
services  needed  for  amphibious  network  agility;  however,  administrative  and  user  benfits 
could  be  negatively  influenced  by  overall  performance  degradations  signature  to  the 
servers’  spinning  disks. 

The  configuration  comparsions  centered  on  modifying  the  configuration  of 
the  HS-22.  One  represented  the  COTS  standard  configuration.  The  other  server  had  a 
Fusion-IO,  solid-state  drive,  PCI  card  connected  for  storage.  The  comparision  occurred 
simulating  a  boot-storm,  multiple  users  logging  on  at  an  instant,  while  observing  CPU 
processing  and  memory  differences.  On  a  smaller  scale  of  five  and,  later,  twenty  users 
logging  on,  the  servers  with  the  Fusion-IO  PCI  card  consistently  utilized  less  CPU 
processing  and  accessed  more  memory  faster,  nearly  instantly  as  depicted  in  Table  3. 


IBM  HS-22  (COTS) 

IBM  HS-22  (With  Fusion  lo  and  PCI 
Card) 

5  VMs 

20  VMS 

CPU 

Usage 

CPU 

Capacity 

Memory 

Usage 

Memory 

Capacity 

CPU 

Usage 

CPU 

Capacity 

Memory 

Usage 

Memory 

Capacity 

246 

MHz 

8.532 

GHz 

3388 

MB 

16383.05 

MB 

224 

GHz 

35469 

MB 

49140.05 

MB 

%  CPU  Usage 

%  Memory  Usage 

%  CPU  Usage 

%  Memory  Usage 

0.0288 

0.2067 

0.00653 

0.7217 

Table  3.  Comparison  of  5  VMs  Utilizing  IBM  HS-22  Configuration  vs. 

20  VMs  Utilizing  IBM  HS-22  with  Fusion  lo  and  PCI  Card 
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VI.  RE-ENGINEERING  AMPHIBIOUS  INTEGRATION 


A.  TECHNOLOGY  PROPOSAL 

NPS  IS4220  and  IS4250  course  materials  reeommend  when  ineorporating  higher 
levels  of  proeess  integration,  a  teehnology,  portal  and  middleware,  is  needed.  Previous 
researeh,  ineluding  field  testing  during  Trident  Warrior  2011,  led  to  a  teehnology 
insertion  designed  to  support  a  re-engineered  network  integration  proeess.  Virtual 
Desktop  Infrastructures  (VDIs)  eould  allow  ship-hosted  desktop  eapabilities  for 
inorganie/embarking  workstations  regardless  of  their  hardware  and  software 
ineompatibilities  to  all  DoD  and  subsequent  policies.  A  VDI  eould  provide  the  virtual 
portal  for  a  virtual  elient,  effectively  aeting  as  middleware.  As  long  as  the  loeal  servers 
and  network  infrastrueture  eould  aeeommodate  a  requested  number  of  “virtual  desktops,” 
they  would  be  seeurely  pushed  to  any  terminal  eonneeted.  VDI  teehnology  insertion 
eould  direetly  address  the  areas  needed  for  improvement  introdueed  while  defining  the 
eurrent  view. 

1,  Revised  Enterprise  Architecture 

Observations  from  the  existing  integration  proeess  revealed  a  multitude  of 
supporting  aetivities  eontributing  overall  inefficieney  and  low  operational  agility.  Large 
durations  of  time  are  spent  waiting  for  workstations  to  be  separately  brought  into 
eompliance.  When  in  possession  of  the  embarking  eomputers,  functional  workers  are 
utilized  beyond  rational  limits.  The  VDI  teehnology  proposal  enables  a  ship’s  IT  erew  to 
no  longer  take  custody  of  inorganic  equipment.  As  long  as  the  eapacity  exists  on  the 
servers  and  switehes,  fully  eompliant  virtual  elients  ean  be  ereated  and  pushed  to  drops 
within  seeonds.  Any  updates  requisite  of  0/S,  ship  image,  or  seeurity  pateh  is  eompleted 
at  the  server  upon  an  enterprise  virtual  elient  that  is  replieated  and  shared. 

2,  Re-Engineering  Goals 

Upon  presenting  the  results  of  our  eurrent  proeess,  we  were  instrueted  to  meet  the 
following  Business  Proeess  Re-Engineering  goals: 
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a)  Reduce  the  total  duration  to  less  than  or  equal  to  7  days. 

b)  Reduce  utilization  for  each  to  less  than  70%. 

c)  Reduce  overall  wait-time  by  90%. 

In  order  to  meet  our  goals,  nearly  every  aspect  of  the  current  process  stood  in 
question.  Sub-processes  and  their  functional  personnel  had  to  be  scrutinized  for  their 
necessity  and  contribution  to  the  overall  desired  output.  Technology  solutions  were 
sought  to  alleviate  potentially  needless  activity.  The  Process  Re-Engineering  section 
provides  detail  to  the  solutions  we  applied  approach  the  assigned  goals. 

3  Process  Re-Engineering 

Previous  research,  including  field  testing  during  Trident  Warrior  2011,  led  to 
technology  insertion  to  improve  the  re-engineered  network  integration  process.  Virtual 
Desktop  Infrastructures  (VDIs)  could  allow  ship-hosted  desktop  capabilities  to 
inorganic/embarking  workstations  regardless  of  their  hardware  and  software 
incompatibilities  to  all  DoD  and  subsequent  policies.  As  long  as  the  local  servers  and 
network  infrastructure  could  accommodate  a  requested  number  of  “virtual  desktops,” 
they  would  be  securely  pushed  to  any  terminal  connected.  With  VDI  capability,  the  new 
process  emerged; 

e)  JNOC  receives  a  request  to  integrate  a  quantified  number  of  workstations 

onto  the  ship’s  network.  Servers  are  checked  to  verify  if  the 
capacity  exists  to  host  the  requested  virtual  clients  (with  nominal 
processor,  RAM,  and  storage  performance)  and  manage  the 
connected  workstations.  Overall  count  is  determined  and  DSR 
validates  if  the  network  infrastructure  can  support  the 
clients/workstations  at  the  requested/assigned  ship  space. 

f)  b)  Either  remotely  or  locally  on  the  ship’s  servers,  ADP  and  lA  verify  the 

necessary  0/S  updates  and  security  measures  are  current  on  the 
enterprise  virtual  client,  respectively. 

g)  JNOC  builds  the  required  virtual  clients  to  support  the  embarking 

organization.  Simultaneously,  DSR  assigns  and  enables  ports 
associated  with  the  drops  within  arranged  ship 
spaces/compartments. 
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h)  The  embarking  IT  personnel/customer  delivers  an  operable  workstation 

(laptop,  desktop,  or  thin  elient  device)  to  a  directed  ship  space. 
JNOC  assists  with  the  workstation  set  up  and  coordinates  with 
DSR  to  ensure  the  workstation  successfully  connects  to  the 
network  and  receives  the  virtual  client. 

i)  When  LAN  connection  and  virtual  client  boots,  JNOC  members  turn  over 

the  operation  of  the  workstation  to  the  embarkee  for  a  courtesy 
quality-assurance  check. 

4.  Generalizations  for  Re-Engineering 

The  introduction  of  a  VDI  and  efforts  to  meet  assigned  goals  forced 
generalizations  to  be  made  for  the  TO-BE  model,  BPR  of  shipboard  network  integration. 
They  are  provided  here: 

a.  VDI  technology  insertion:  Desktop  virtualization  alleviates  the  ship’s 
IT  crew  from  previous  sub-processes,  and  their  resulting  bottlenecks,  dealing  with 
workstation  transport/hand-over  and  the  requisite  hours  for  hardware/software 
compliance.  Initial  workstation  operability,  inventories  and  accountability  remain  with 
the  embarking  IT  organization’s  personnel.  Trouble-shooting,  slicking,  re-imaging, 
updating,  and  patching  approved  hardware  is  no  longer  necessary.  Nearly  any  network- 
capable  device  can  receive  a  virtual  desktop. 

b.  Sub-Process  Duration:  VDI  insertion  into  the  TO-BE  model  process 
not  only  removed  former  processes,  it  also  gave  a  greater  agility  to  resulting  activities. 
Rather  than  ADP  and  lA  individually  installing  updates  and  security  patches,  both  need 
only  to  ensure  their  enterprise  versions  are  current,  which  is  done  at  the  server  or 
remotely  in  minutes.  With  JNOC  and  DSR  freed  from  deliveries  and  trouble-shooting, 
their  time  can  be  concentrated  and  better  utilized  toward  the  refined  activities. 
Maintaining  300  instances  within  a  scenario  and  reducing  the  overall  duration  called  for 
additional  personnel  within  each  functional  group. 

c.  Decision  Probabilities:  Decision  points  and  their  probabilities  were 
required  to  be  readdressed.  Server  and  network  infrastructure  capacity  decisions  were 
still  necessary  to  meet  requests  of  various  arrangements  of  embarking  personnel  and 
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workstations;  however  VDI  hardware  components  allow  for  greater  capacities  from  the 
ship’s  hosting  server.  Also,  final  JNOC  operational  testing  of  the  workstations  is 
conducted  after  the  initial  check,  from  embarking  personnel  have  proven  it  functional. 
Also,  all  decisions  made  through  DSR  swim-lanes  remain  consistent  with  the  AS-IS 
model. 

d.  Associated  Costs:  Where  the  current  process  assumed  only  two 
personnel  at  any  time  during  a  workday  are  focused  upon  an  integration  activity,  goals  in 
overall  duration,  utilization,  and  wait-time  required  more  support.  AS-IS  pay-grades  did 
remain  the  same;  however,  a  more  detailed  study  could  distinguish  a  more  realistic 
dispersion  of  enlisted  pay-grades.  Overall  numbers  of  supporting  IT  personnel  do  stay 
true  to  shipboard  and  MEU  manning. 
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VII.  CONCLUSION 


Currently,  LHD/LHAs  are  being  assigned  a  broad  range  of  missions  where 
formerly  disparate  organizations  must  quiekly  and  seamlessly  integrate  to  begin 
addressing  the  task  ahead.  Although  used  for  laek  of  alternatives,  AS-IS  eore  proeesses’ 
striet  foeus  on  standardization  interferes  with  eritieal  timeliness  and  full  integration. 
Field  testing  VDI  insertion,  like  efforts  within  Trident  Warrior  2011,  peer  into  a  new 
arehiteeture  where  mission  planning  expeetations  ean  be  met.  No  other  teehnology 
shows  as  mueh  promise  to  allow  supported  proeesses  be  in  aeeord  with  an  organizing 
logie  of  unifieation.  Field  tests  lead  to  full  enterprise  deployment;  however,  only  through 
a  well-thought  Enterprise  Arehiteeture,  ean  teehnology  determine  sueeess. 

With  nearly  limitless  eombinations  of  options,  we  maintained  a  foeus  on  our  goals 
and  ereated  a  tailored,  yet  praetieal,  LHD/LHA  VDI  eapable  of  hosting  any  embarking 
organization.  The  eondueted  BPR  transformed  the  integration  proeess  and  provided 
insight  to  manning  levels,  as  well.  In  order  to  meet  the  preseribed  requirements,  eaeh 
funetional  workplaee  had  to  inerease  their  supporting  personnel.  We  found  the  optimal 
blend  to  be:  12  members  within  the  embarking  organization,  11  within  JNOC,  7 
supporting  DSR,  and  4  eaeh  in  ADP  and  lA.  Any  deviation  from  this  arrangement  led  to 
missing  our  goals  or  drifting  into  unrealistie  manning  levels.  Addressing  eaeh  goal: 

a)  Reduee  the  total  duration  to  less  than  or  equal  to  7  days: 

TO-BE  model  resulted  in  less  than  10  hours  of  overall  duration.  Nearly  full 
eommitment  of  ship’s  IT  personnel  eould  integrate  a  MEU’s  full  UNCEAS  network 
integration  in  one  extended  working  day.  If  done  after  normal  working  hours,  the 
integration  eould  have  very  little  impaet  on  overall  operations. 

b)  Reduee  utilization  for  eaeh  to  less  than  70%: 

Utilization  pereentages  of  JNOC  and  “Embarkee  QA”  personnel  were  only 
slightly  above  threshold,  72%  and  70%,  respeetively.  The  TO-BE  model  required 
unrealistie  numbers  within  these  two  groups  in  order  further  reduee  their  utilization. 
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Being  well  below  80%,  their  workload  through  the  revised  integration  proeess  is 
aeeeptable.  Utilization  for  DSR,  ADP,  and  lA  were  able  to  fall  below  our  instructed 
ceiling. 


c)  Reduce  overall  wait-time  by  90%: 

Another  drastic  improvement  from  the  current  integration  process  was  the 
reduction  in  wait-time.  The  TO-BE  model  produced  a  93%  reduction  in  overall  waiting 
time  from  22,548  to  1656  and  is  illustrated  in  Table  4. 

Admittedly,  our  BPR  is  limited  to  our  experiences,  data  collected,  and  necessary 
assumptions.  Overall,  the  current  personnel,  processes,  and  technology  regarding 
workstation  network  integration  for  a  specific  platform  has  been  accurately  captured. 
Without  exception,  all  input  received  addressing  each  area  in  the  AS-IS  architecture  has 
shown  much  room  for  improvement.  Our  research  reveals  that  addressing  solely 
personnel,  processes,  technology,  or  a  combination  of  only  two,  will  not  yield  a  sufficient 
solution  to  current  enterprise  practices  and  resources.  It  is  in  the  best  interest  for  the  U.S. 
Navy  to  pursue  multiple  means  for  interoperability. 


Simulation  Results 


Duration  9:45:20Time 


Process  Time  And  Cost 

Pwess 

Scenario 

T(tfal&it 

Waiting  Time 
t^e) 

TotatTine 

Matthias  Becker  Gruber  ToBe 

(default) 

300 

3795.43 

1656:11:20 

1402:45:00 

Performers  Queue  Length  and  Utilization 


Nam 

Avs^e 

Uin 

Max 

I(Se(%) 

Anv  member  of  JNOC 

39.19 

0 

174 

72.83 

27.17 

Anv  member  of  EMBARKEE  OA 

35.13 

0 

122 

70.9 

29.1 

Anv  member  of  ADP 

16.31 

0 

55 

56.59 

43.41 

Anv  member  of  DSR 

86.76 

0 

230 

68.34 

31.66 

Anv  member  of  lA 

16.31 

0 

55 

56.59 

43.41 

Table  4.  TO-BE  Amphibious  LAN  Integration  Metrics 
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A,  FOLLOW  ON  RESEARCH  RECOMMENDATIONS 

The  findings  from  this  research  have  led  to  further  questions  and  areas  of  interest 
that  could  be  tapped  for  future  research.  The  view  of  this  research  was  from  a  broad  view 
that  maintained  a  wide  scope  which  left  open  the  opportunity  for  further  analysis  and  in- 
depth  research  in  the  realms  of  technology,  personnel  management  and  costs  with  regards 
to  VDI  technology  onboard  Naval  vessels. 

This  thesis  focused  on  one  configuration  of  VDI  that  was  considered  to  be  the 
most  easily  achievable  through  the  use  of  minimal  changes  to  technology  onboard 
LHA/LHDs  while  providing  the  most  benefit  in  terms  of  performance  and  reduction  in 
man  hours  and  overall  manning.  There  is  obviously  much  more  technology  available  to 
the  market  than  what  was  discussed  and  these  additional  technologies  may  present 
possibilities  for  future  research.  Follow  on  research  may  be  able  to  discover  better 
performing  technologies  or  technological  methods  that  push  past  the  goals  of  this 
research  and  open  up  new  possibilities  in  the  endeavor  to  integrate  and  jointly  operate. 

Although  only  LHA/LHDs  were  discussed,  other  platforms  would  greatly  benefit 
from  the  ability  to  be  able  to  embark  Marines  and  personnel  from  disparate  groups.  One 
notable  and  new  platform  that  would  greatly  benefit  from  ability  to  embark  groups  of 
personnel  and  give  them  computing  capability  quickly  and  efficiently  is  the  Littoral 
Combat  Class  platforms.  These  new  platforms  are  designed  to  embark  and  debark 
personnel.  Sailors,  Marines  and  Civilians  as  part  of  LCS’s  mission  module  systems.  The 
mission  modules  require  additional  equipment  and  personnel  to  embark  upon  the  ships, 
requiring  Internet  access,  network  access,  and  computing  capabilities  for  completion  of 
mission  tasking  and  basic  administration.  Despite  the  massive  size  difference  between  a 
large  deck  amphibious  vessel  and  a  Littoral  Combat  Ship,  the  needs  are  almost  the  same. 
Follow  on  research  could  be  used  to  determine  if  VDI  could  be  a  solution  to  the 
challenges  faced  onboard  LCS  and  what  technology  and  methods  could  be  utilized  in 
order  to  meet  needs  of  embarking  personnel  and  equipment. 

Further  research  could  be  leveraged  onboard  LCS  and  other  small  platforms  in 
terms  of  personnel  manning.  The  goals  of  this  thesis  were  to  greatly  reduce  the  amount  of 
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time  spent  on  embarkable  computing  needs  and  the  total  amount  of  manning  required  to 
accomplish  embarking  personnel.  It  was  found  that  through  the  use  of  VDI  these 
objectives  could  be  met  and  the  total  time  and  total  amount  of  personnel  could  be 
reduced.  The  benefits  in  the  reduction  of  man-hours  required  and  the  amount  of  personnel 
required  would  be  huge  onboard  platforms  like  LCS,  which  is  manned  by  a  total  of  forty 
Sailors.  With  so  few  Sailors  and  requirements  similar,  but  at  a  lesser  scale,  as  the  larger 
vessels,  reduction  is  manning  through  improved  processes  and  technology  is  an  area  of 
research  that  could  open  up  LCS,  smaller  platforms  and  the  Navy  as  whole  to  more 
mission  flexibility  and  speed. 

An  area  not  covered  but  of  interest  is  the  monetary  cost  of  VDI  systems  and  the 
implementation  onboard  Naval  vessels.  Further  research  could  be  used  to  determine  costs 
associated  with  upgrading  to  and  installing  VDI  systems  onboard  Naval  vessels.  Costs 
through  the  reduction  of  personnel  and  man  hours  spent  could  also  be  tested  and 
researched  in  order  to  determine  if  the  costs  associated  with  the  upgrades  and  install 
could  be  offset  and  surpassed  through  the  cost  savings  from  the  reduction  of  man  hours 
and  the  reduction  total  manning  to  support  onboard  networks. 
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